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ABSTRACT 

In  2003  the  author  attended  the  AEW&C  Operational  Mission  System  (OMS)  simulator 
preliminary  design  review.  The  design  for  the  Distributed  Interactive  Simulation  (DIS) 
interface  on  this  simulator  was  not  well  developed  and  a  significant  amount  of  work  was 
required  to  bring  the  AEW&C  OMS  simulator's  DIS  interface  up  to  a  suitable  standard  to 
provide  a  useful  level  of  interoperability.  This  report  documents  the  processes  used  to 
develop  a  minimum,  basic  set  of  DIS  message  packets  (Protocol  Data  Units  (PDUs))  that 
should  provide  sufficient  interoperability  to  enable  the  (or  any  other  ADF)  simulator  to 
participate  in  a  DIS,  Wide  Area  Network,  training  exercise  at  the  time  the  simulator  is 
accepted  by  the  ADF  without  expensive  after  acceptance  modification. 

Although  used  for  the  AEW&C  OMS  simulator  the  recommended,  base,  minimum  set  of  DIS 
PDUs  is  not  directed  at  any  particular  platform  or  project  and  is  meant  to  be  the  generic 
starting  point  for  any  ADF  simulator  DIS  interface.  An  analysis  of  platform  specific 
functionality  would  also  be  required  to  provide  additional  platform  specific  DIS  PDUs. 
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What  Distributed  Interactive  Simulation  (DIS) 
Protocol  Data  Units  (PDU)  Should  My 
Australian  Defence  Force  Simulator  Have? 


Executive  Summary 

In  2003  the  author  attended  the  AEW&C  Operational  Mission  System  (OMS)  simulator 
preliminary  design  review.  The  Distributed  Interactive  Simulation  (DIS)  interface  on 
this  simulator  was  not  well  developed  and  a  significant  amount  of  work  was  required 
to  bring  the  AEW&C  OMS  simulator’s  DIS  interface  up  to  a  suitable  standard  to 
provide  a  useful  level  of  interoperability. 

This  report  documents  the  processes  used  to  provide  a  minimum,  basic  set  of  DIS 
message  packets  (Protocol  Data  Units  (PDUs))  that  should  provide  sufficient 
interoperability  to  enable  this  (or  any  other  Australian  Defence  Force  (ADF))  simulator 
to  participate  in  a  DIS,  Wide  Area  Network,  training  exercise  at  the  time  the  simulator 
is  accepted  by  the  ADF  without  expensive  after  acceptance  modification. 

Although  used  for  the  AEW&C  OMS  simulator  the  recommended,  base,  minimum  set 
of  DIS  PDUs  is  not  directed  at  any  particular  platform  or  project  and  is  meant  to  be  the 
generic  starting  point  for  any  ADF  simulator  DIS  interface.  An  analysis  of  platform 
specific  functionality  would  also  be  required  to  provide  additional  platform  specific 
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1.  Introduction 

Over  the  next  decade  the  Australian  Defence  Force  (ADF)  will  continue  to  develop  and 
acquire  platform  training  simulators  for  air,  maritime  and  land  assets.  Many  of  these 
simulators  will  have  the  capability  of  being  networked  together  using  Advanced 
Distributed  Simulation  (ADS).  The  adoption  of  such  ADS  technologies  will  enable 
increased  and  enhanced  training  capabilities  and  opportunities  at  reduced  costs  [1, 2], 

Existing  network-enabled  training  simulators  include  the  Royal  Australian  Navy's 
(RAN)  Integrated  Operations  Team  Training  Facility  (IOTTF)  FFG  ship  and  Combat 
System  Tactical  Trainer  (CSTT)  Anzac  ship  simulators  located  at  the  Maritime  Warfare 
Training  Centre  (MWTC)  [3,  4,  5]  at  HMAS  Watson,  the  Royal  Australian  Air  Force's 
(RAAF)  AP-3C  simulator  [6,  7]  located  at  RAAF  Edinburgh  and  the  RAAF  DSTO 
developed  Air  Defence  Ground  Environment  SIMulator  (ADGESIM)  [8  9]  used 
operationally  at  RAAF  Williamtown  and  RAAF  Darwin.  Other  platform  simulators, 
which  may  be  networked  in  the  future,  include  the  Seasprite,  Seahawk,  and  Armed 
Reconnaissance  Helicopter  simulators,  the  Collins  submarine  simulator,  the  FFG  UP 
simulator  [10]  and  the  Airborne  Early  Warning  &  Control  (AEW&C)  Operational 
Mission  System  simulator  [11,  12],  Section  2  gives  an  overview  of  Distributed 
Simulation  in  the  ADF. 

In  2003  the  author  attended  the  AEW&C  Operational  Mission  System  simulator 
preliminary  design  review  (PDR)  [13].  The  Distributed  Interactive  Simulation  (DIS) 
interface  on  this  simulator  was  insufficiently  developed  and  a  significant  amount  of 
work  was  required  to  provide  the  project  with  advice  on  what  protocols  were  required 
to  bring  the  simulator's  ADS  interface  to  a  suitable  and  useful  standard. 

This  report  documents  the  processes  used  to  provide  a  minimum,  basic  set  of  DIS 
Protocol  Data  Units  (PDUs)  that  could  be  implemented  by  any  ADF  DIS  simulator. 
This  basic  set  of  DIS  PDUs  should  provide  sufficient,  application  protocol 
interoperability  to  enable  the  simulator  to  participate  in  a  DIS,  Wide  Area  Network, 
training  exercise  at  the  time  the  simulator  is  accepted  by  the  Commonwealth  (ie 
without  expensive  after  acceptance  modification). 

There  may  be  several  ways  to  determine  what  DIS  Protocol  Data  Units  (PDUs)  should 
be  used  in  a  platform  simulator  to  achieve  the  required  application  protocol 
interoperability.  Two  such  processes  are  used  in  section  6  to  produce  the 
recommended,  minimum,  starting  set  of  DIS  PDUs  required  for  any  ADF  DIS 
simulator. 

Although  used  for  the  AEW&C  Operational  Mission  System  simulator  project,  the 
recommended,  minimum,  basic  set  of  DIS  Protocol  Data  Units  (PDUs)  is  not  directed  at 
any  particular  platform  or  project  and  thus  a  set  of  platform  specific  capabilities  is  not 
required  for  analysis.  The  approach  used  in  this  report  is  to  use  the  author's  experience 
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with  particular  ADF  DIS  simulator  projects  (RAN  HMAS  Watson  IOTTF  and  CSTT, 
RAN  FFG  UP,  RAAP  AP-3C  OMS,  RAAF  AEW&C  OMS,  and  RAAF  ADGESIM 
simulators)  to  discuss  and  compare  the  commonly  used  DIS  PDUs  in  such  simulators. 
This  methodology  should  give  a  basic  set  of  DIS  PDUs  required  to  provide  an 
acceptable  level  of  application  protocol  interoperability. 

In  addition,  the  functions  specifically  carried  out  by  the  platform  to  be  simulated 
would  also  need  to  be  analysed.  The  additional  DIS  PDUs  required  to  specifically 
support  distributed  training  of  this  particular  platform's  capabilities  can  then  be 
determined  [3].  For  example  if  the  platform  being  simulated  is  required  to  search  for 
submarines  the  platform  simulator  will  most  likely  need  to  support  the  Underwater 
Acoustics  PDU.  An  F/A-18  aircraft  is  unlikely  to  have  such  a  capability  and  therefore 
an  F/A-18  simulator  would  not  be  required  to  support  this  PDU. 

The  author  is  also  involved  in  the  development  of  the  RAAF  Virtual  Air  Environment 
(VAE)  ADGESIM  simulator  [8,  9]  and  the  results  of  this  report  will  be  used  to  upgrade 
the  DIS  interface  of  the  ADGESIM  simulator  to  attain  the  recommended  level  of 
interoperability. 

To  familiarise  the  reader  with  DIS  a  general  discussion  of  DIS  is  given  in  section  3  - 

What  Is  DIS? 

2.  Advanced  Distributed  Simulation  in  Australia 

Significant  technology  demonstrations  in  Australia  have  shown  the  value  of 
distributed  simulation,  and  have  contributed  to  the  planned  delivery  of  simulation 
systems  to  the  ADF. 

2.1  The  VAE  Demonstrations 

Four  VAE  demonstrations  [14-18]  have  demonstrated:  interoperability  between 
Human-In-The-Loop  and  Computer  Generated  Forces  simulators  from  different 
services  using  DIS;  the  use  of  computer  controlled  artificial  agents  as  enemy  forces;  the 
capability  to  fuse  and  correlate  data  from  and  into  dissimilar,  real  sensor  systems;  and 
the  use  of  DIS  voice  communications  all  connected  on  a  geographically  dispersed  Wide 
Area  Network  (WAN). 

2.2  The  SimTecT2002  Synthetic  Environment  Demonstration 

DIS  and  Higher  Level  Architecture  (HLA)  simulators  from  the  Australian  Army,  Navy 
and  Air  Force  interoperated  in  the  SimTecT2002  demonstration.  A  USN  system  (Battle 
Force  Tactical  Training  Operator  Processor  Console  -  BOPQ  also  participated.  Defence 
and  Industry  resources  combined  to  showcase  this  demonstration.  Current  operational 
and  future  (Armed  Reconnaissance  Helicopter,  Global  Hawk  and  Wedgetail  AEW&C 
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aircraft)  capabilities  participated,  highlighting  the  tiaining,  research  and  acquisition 
potential  of  a  synthetic  environment. 

2.3  The  Australian  /  US  Navy  Distributed  Simulation  Coalition 
Training  Exercises 


The  US  Navy's  Battle  Force  Tactical  Training  (BFTT)  Program  provides  on-board 
training  using  DIS  to  naval  fleet  units.  This  technology  enables  a  number  of  ships  and 
shore  units  to  participate  in  the  same  virtual  battlespace  even  though  they  may  be 
geographically  dispersed. 

Australia  and  the  United  States  are  collaborating  in  the  area  of  simulation  for  training 
via  both  a  RAN/USN  Heads  of  Agreement  and  a  DSTO/USN  Project  Arrangement. 
This  collaboration  will  ultimately  ensure  that  Australian  Navy  training  systems  both  in 
the  ships  and  ashore  will  be  able  to  interoperate  with  their  USN  counterparts.  The 
RAN  would  then  be  able  to  participate  in  virtual  coalition  training  exercises  with  the 
USN  without  needing  to  send  ships  and  crews  to  designated  exercise  areas  [11]. 

Tire  main  objective  of  these  coalition,  training  exercises  is  to  enhance  warfighting 
readiness  through  the  development  of  a  coalition  team  training  and  combined  mission 
rehearsal  capability  [11, 19,  20].  The  first  such  exercise  joined  operational  team  training 
simulators  at  HMAS  Watson  with  USN  training  simulators  at  Dam  Neck,  Virginia  and 
the  I/ITSEC  2001  Conference  floor  at  Orlando,  Florida.  The  Netherlands  Navy  also 
participated  from  the  TNO  in  the  Netherlands.  DSTO  provided  technical  assistance 
and  analysis  of  the  data  from  this  unclassified  exercise. 

Connectivity  between  these  locations  was  established  using  commercial  ISDN  WAN 
service  providers  (eg  Telstra  in  Australia).  DIS  Entity  and  DIS  radio  communication 
interoperability  was  achieved.  Video  conferencing  was  provided  to  assist  both  the  set 
up  and  the  After  Action  Review  processes.  Learning  methodology  research  was  also 
carried  out  during  this  exercise  [8,  21]. 

The  next  exercise,  in  February  2003,  built  on  knowledge  and  experience  gained  from 
tiie  I/ITSEC  2001  exercise.  The  February  2003  exercise  was  classified  and  also 
implemented  a  TADIL  Link  11  capability.  Classified  WAN  exercises  introduce  security 
and  encryption  issues.  Lessons  learned  from  this  February  2003  training  exercise  will 
most  likely  benefit  all  future  ADF  distributed  simulation  exercises. 

On  completion  of  this  exercise,  coupled  with  all  the  other  demonstrations  and  exercises 
already  carried  out  in  Australia,  many  of  the  relevant  distributed  simulation 
technologies  required  during  a  typical  classified,  joint,  coalition,  WAN  training 
exercise  will  have  been  researched,  evaluated  and  installed. 

Because  the  USN/ RAN  simulators  (ie.  BFTT/FFG  Upgrade)  used  in  these  exercises 
will  be  tire  same  as  the  real  on-board  training  systems,  the  laboratory  to  laboratory  and 
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shore  trainer  to  shore  trainer  exercises  could  now  start  the  shift  to  ship  to  ship  training. 
This  will  enable  coalition  mission  rehearsal  on  operational  platforms  -  train  as  we  (ie 
where  we)  fight  [19]. 

2.4  The  DSTO  TOint  Air  Navy  Networking  Environment  Project 
gOANNE) 

DSTO's  Air  Operations  Division  has  initiated  development  of  the  JOANNE  [1, 2, 19-22] 
Project,  JOANNE  will  provide  the  ADF  with  the  technical  architecture  for  a  synthetic 
environment  for  training  using  existing  simulation  facilities.  It  will  benefit  various 
existing  sponsored  projects  including  SEA  1412  and  the  VAE,  and,  through 
multinational  defence  agreements,  seek  to  facilitate  collaboration  with  the  US  Navy  s 
Battle  Force  Tactical  Training  (BFTT)  Program  and  the  US  Air  Force's  Distributed 
Mission  Training  (DMT  -  recently  renamed  Distributed  Mission  Operations  (DMO)) 
Program. 

2.5  The  RAAF  VAE  Project  and  the  RAN  Project  SEA  1412 

Both  the  RAAF  VAE  and  RAN  SEA  1412  Projects  have  historically  followed  similar 
trends. 

Because  of  the  planned  introduction  of  new  Air  Defence  /  Fighter  Control  systems 
(Jindalee  Operational  Radar  Network  (JORN),  Airborne  Early  Warning  and  Control 
(AEW&Q  and  the  Air  Command  Support  System  (ACSS))  and  the  corresponding 
increase  in  Right  Controllers,  live  asset  training  opportunities  per  Right  Controller 
will  diminish  significantly.  The  VAE  Project  was  originally  intended  to  alleviate  these 
Flight  Controller  training  deficiencies  [23].  An  Interim  Training  Capability  (TTQ 
simulator  was  planned  to  be  delivered  by  industry  as  part  of  the  VAE.  However, 
because  of  significant  changes  to  the  scope  and  the  scale  of  the  required  capability,  as 
part  of  VAE  phase  2,  DSTO  has  delivered  its  Air  Defence  Ground  Environment 
Simulator  (ADGESIM)  to  RAAF  Williamtown  in  place  of  the  ITC. 

Initially  SEA  1412  was  developed  to  add  DIS  interfaces  to  the  Anzac  and  FFG/DDG 
simulators  at  HMAS  Watson  to  share  simulator  resources  to  enhance  command  team 
training  and  tactical  development  [3-5].  The  addition  of  a  Wide  Area  Network  (WAN) 
capability  at  HMAS  Watson  and  the  signing  of  a  US  Navy  and  DSTO/RAN  Project 
Arrangement  has  resulted  in  a  series  of  exercises  intended  to  enhance  warfighting 
readiness  through  the  development  of  a  combined  coalition  team  training  and  mission 
rehearsal  capability  [22], 

DSTO  views  these  Projects  (under  JOANNE)  as  the  ADF  joint  component,  virtual 
environments  on  which  research  and  development,  evaluation  and  deployment  of 
research  and  operational,  distributed  simulation  systems  takes  place.  All  such  systems 
should  (where  practical  and  applicable)  comply  with  the  appropriate  DSTO  JOANNE 
standards  to  ensure  the  maximum  probability  of  interoperability  and  scalability  [11]. 
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2.6  Maritime  Warfare  Training  System 

Through  Project  SEA  1412,  the  RAN  is  developing  the  Maritime  Warfare  Training 
System  (MWTS)  which  initially  links  several  existing  surface  warfare  trainers  to 
provide  enhanced  command  team  and  tactical  training  for  the  RAN  into  the  future. 


In  later  phases  of  the  Project,  an  Australian  wide-area  maritime  simulation  network 
will  be  established.  This  system  could  include  ships  alongside  at  die  Fleet  Bases,  linked 
via  their  on-board  training  systems  with  the  wargaming  system  and  ship  models  at 
HMAS  Watson  in  Sydney,  as  well  as  other  ADF  simulators,  such  as  RAN  helicopter 
simulators,  RAAF  AP-3C,  F/A-18  and  AEW&C  aircraft  simulators  [5, 11-12], 

2.7  FFG  On  Board  Training  Systems 

In  parallel  with  development  of  SEA  1412,  the  RAN's  Guided  Missile  Frigates  (FFGs) 
are  acquiring  Distributed  Interactive  Simulation  (DIS)  compatible  On  Board  Training 
Systems  (OBTS)  under  Project  SEA  1390  [10-11],  Interoperability  between  the  FFG 
OBTS  and  the  SEA  1412  systems  will  be  investigated  in  the  DSTO  JOANNE  task.  In 
future,  the  ANZAC  ships  and  Collins  class  submarines  are  likely  to  acquire  DIS- 
compatible  OBTS. 

2.8  RAAF  AP-3C  Simulators 

Under  Project  AIR  5276,  the  RAAF  has  acquired  two  simulators  for  the  new  AP-3C 
aircraft.  These  simulators  comprise  the  'front  end',  Advanced  Flight  Simulator  (AFS) 
and  the  'back  end'.  Operational  Mission  Simulator  (OMS).  Each  of  these  simulators 
have  a  DIS  interface  [6-7,  11]  that  will  allow  the  simulator,  if  required,  to  become  a 
node  in  a  wider  Australian  synthetic  theatre  of  war,  in  particular  providing 
interoperability  with  JOANNE  systems. 

3.  What  Is  Distributed  Interactive  Simulation  (DIS)? 

Connectivity  is  achieved  when  simulators  are  physically  connected  to  the  same 
network.  However  only  when  simulators  interact  appropriately  with  each  other, 
through  the  use  of  common  standards,  is  interoperability  achieved. 

Distributed  Interactive  Simulation  (DIS)  [24-2 7]  is  a  (mainly  US)  govemment/industry 
initiative  to  define  an  interoperability  infrastructure  for  linking  simulations  of  various 
types  at  multiple  locations  to  create  realistic,  complex,  virtual  worlds  for  the  simulation 
of  highly  interactive  activities.  This  interoperability  infrastructure  brings  together 
systems  built  for  separate  purposes,  technologies  from  different  eras,  products  from 
various  vendors,  and  platforms  from  various  services,  and  permits  them  to 
interoperate.  DIS  exercises  are  intended  to  support  a  mixture  of  virtual  entities  with 
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Computer  Generated  Forces  (CGF)  computer  controlled  behavior,  virtual  entities  with 
live  operators  (human-iivthe-loop  simulators),  live  entities  (operational  platforms  and 
test  and  evaluation  systems),  and  constructive  entities  (war-games  and  other 
automated  simulations).  DIS  draws  heavily  on  experience  derived  from  the  Simulator 
Networking  (SIMNET)  program  developed  by  the  Advanced  Research  Projects  Agency 
(ARP A),  adopting  many  of  SIMNET's  basic  concepts  and  heeding  lessons  learned. 

In  order  for  DIS  to  lake  advantage  of  current  and  future  simulations  developed  by 
different  organisations,  a  means  had  to  be  found  for  assuring  interoperability  between 
dissimilar  simulations.  These  means  were  developed  in  the  form  of  industry  consensus 
standards.  The  open  forum  (including  government,  industry,  and  academia)  chosen  for 
developing  these  standards  was  a  series  of  semi-annual  Workshops  on  Standards  for 
the  Interoperability  of  Distributed  Simulations  that  began  in  1989.  The  results  of  the 
workshops  have  been  several  IEEE  standards.  These  standards  provide  application 
protocol,  communication  services  and  recommended  implementation  standards  to 
support  DIS  interoperability. 

DIS  is  also  defined  as:  a  time  and  space  coherent  synthetic  representation  of  world 
environments  designed  for  linking  the  interactive,  free-play  activities  of  people  in 
operational  exercises.  The  synthetic  environment  is  created  through  real-time  exchange 
of  data  units  between  distributed,  computationally  autonomous  simulation 
applications  in  the  form  of  simulations,  simulators,  and  instrumented  equipment 
interconnected  through  standard  computer  communicative  services.  These  DIS 
Protocol  Data  Units,  the  DIS  data  messages  that  are  passed  on  a  network  between 
simulation  applications  according  to  a  defined  protocol,  are  issued  by  all  simulation 
applications  participating  in  the  same  exercise.  The  participating  simulation 
applications  may  be  present  in  one  location  or  may  be  distributed  geographically  [24- 
26], 

3.1  Basic  Architecture  Concepts 

The  basic  architecture  concepts  for  DIS  are  [25]: 

a)  No  central  computer  controls  the  entire  simulation  exercise.  Some  simulation 
systems  have  a  central  computer  that  maintains  the  world  state  and  calculates 
the  effects  of  each  entity's  actions  on  other  entities  and  the  environment.  These 
computer  systems  must  be  sized  with  resources  to  handle  the  worst-case  load 
for  a  maximum  number  of  simulated  entities.  DIS  uses  a  distributed  simulation 
approach  in  which  the  responsibility  for  simulating  the  state  of  each  entity  rests 
with  separate  simulation  applications  residing  in  host  computers  connected  via 
a  network.  As  new  host  computers  are  added  to  die  network,  each  new  host 
computer  brings  its  own  resources, 

b)  Autonomous  simulation  applications  are  responsible  for  maintaining  the  state  of  one  or 
more  simulation  entities.  Simulation  applications  (or  simulations)  are 
autonomous  and  generally  responsible  for  maintaining  the  state  of  at  least  one 
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entity.  In  some  cases,  a  simulation  application  will  be  responsible  for 
maintaining  the  state  of  several  entities.  As  the  user  operates  controls  in  the 
simulated  or  actual  equipment,  the  simulation  is  responsible  for  modeling  die 
resulting  actions  of  the  entity  using  a  simulation  model.  That  simulation  is 
responsible  for  sending  messages  to  others,  as  necessary,  to  inform  them  of  any 
observable  actions.  All  simulations  are  responsible  for  interpreting  and 
responding  to  messages  of  interest  from  other  simulations  and  maintaining  a 
model  of  the  state  of  entities  represented  in  the  simulation  exercise.  Simulations 
may  also  maintain  a  model  of  the  state  of  the  environment  and  non-dynamic 
entities,  such  as  bridges  and  buildings  that  may  be  intact  or  destroyed. 

c)  A  standard  protocol  is  used  for  communicating  ground  truth  data.  Each  simulation 
application  communicates  the  state  (which  is  herein  called  ground  trudi)  of  the 
entity  it  controls/measures  (location,  orientation,  velocity,  articulated  parts 
position,  etc.)  to  other  simulations  on  the  network.  The  receiving  simulation  is 
responsible  for  taking  this  ground  truth  data  and  calculating  whether  the  entity 
represented  by  the  sending  simulation  is  detectable  by  visual  or  electronic 
means.  This  perceived  state  of  the  entity  is  then  displayed  to  the  user  as 
required  by  the  individual  simulation. 

d)  Changes  in  die  state  of  an  entity  are  communicated  by  its  controlling  simulation 
application. 

e)  Perception  of  events  or  other  entities  is  determined  by  the  receiving  application. 

f)  Dead  reckoning  algorithms  are  used  to  reduce  communications  processing.  A  method 
of  position/  orientation  estimation,  called  dead  reckoning,  is  used  to  limit  the 
rate  at  which  simulations  must  issue  state  updates  for  an  entity.  Each 
simulation  maintains  an  internal  model  of  the  entity  it  represents.  In  addition, 
the  simulation  maintains  a  dead  reckoning  model  of  its  entity.  The  dead 
reckoning  model  represents  the  view  of  that  entity  by  other  simulation 
applications  on  the  network  and  is  an  extrapolation  of  position  and  orientation 
state  using  a  specified  dead  reckoning  algorithm.  On  a  regular  basis,  the 
simulation  compares  the  internal  model  of  its  entity  to  the  dead  reckoning 
model  of  the  entity.  If  the  difference  between  the  two  exceeds  a  predetermined 
threshold,  the  simulation  will  update  the  dead  reckoning  model  using  the 
information  from  the  internal  model.  At  the  same  time,  the  simulation  will  send 
updated  information  to  other  simulations  on  the  network  so  that  they  can 
update  their  dead  reckoning  model  of  the  entity.  By  using  dead  reckoning, 
simulations  are  not  required  to  report  the  status  of  their  entities  as  often  as  they 
would  otherwise. 

4.  What  Do  I  Need  To  Know  About  DIS  and  What 
Parts  (PDUs)  Do  I  Need? 


Specific  DIS  PDU  information  is  described  in  detail  below.  This  information  has  been 
summarised  from  the  relevant  IEEE  1278  documentation  [25-26],  For  more  detailed 
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information  the  reader  is  encouraged  to  read  the  IEEE  1278.1  and  1278.1a 
documentation. 

4.1  Versions  of  DIS 

The  numerical  values  of  the  PDU  data  fields  and  what  they  represent  in  the  DIS  PDU 
packets  are  defined  in  a  document  titled  "Enumeration  and  Bit  Encoded  Values  for  Use 
zoith  Protocols  for  Distributive  Interactive  Simulation  Applications"  [27], 

Users  can  add  new  enumeration  values  for  DIS  PDU  data  fields  into  this  standard.  This 
enumerations  document  is  updated  annually  and  is  available  from  the  Simulation 
Interoperability  Standards  Organization  World  Wide  Web  site  [27]. 


The  latest  (2003)  enumerations  document  [27]  specifies  the  accepted  DIS  Protocol 
Versions  as  shown  in  Table  1. 

Table  1.  DIS  Protocol  Version  Numbers 


DIS  Version  Number 

DIS  Protocol  Version 

0 

Other 

1 

DIS  1.0  (May  1992) 

2 

IEEE  1278  - 1993 

3 

DIS  2.0.3  (May  1993) 

4 

DIS  2.0.4  (March  16, 1994) 

5 

IEEE  1278.1 -1995 

6 

IEEE  1278.1a  - 1998 

DIS  has  undergone  the  IEEE  standardisation  process  three  times.  The  IEEE  1278  set  of 
standards  define  an  interoperable  (DIS)  simulated  battle  environment  The  IEEE  1278.1 
(1995)  and  1278.1a  (1998)  standards  define  the  DIS  Protocol  Data  Units  (PDUs)  -  date 
messages  that  are  exchanged  on  a  network  between  simulation  applications.  The  IEEE 
1278  standard  describes  10  PDUs.  The  IEEE  1278.1  standard  describes  the  27  PDUs 
defined  up  to  1995.  The  IEEE  1278.1a  standard  describes  the  additional  40  PDUs  added 
in  1998  -  it  does  not  contain  the  information  available  in  the  1995  1278.1  standard.  All 
DIS  simulators  should  be  able  to  interoperate  using  the  latest  (IEEE  1278.1a  -  1998) 
version  of  DIS. 

PDU  types  were  designed  to  be  backward  compatible  -  new  PDU  types  were  added 
but  the  existing  PDU  types  were  generally  not  modified  however  there  have  been  some 
minor  changes.  When  DIS  Version  5  (IEEE  1278.1)  was  released,  an  8-bit  date  field  in 
the  PDU  Header  Record  (the  common  first  part  of  every  DIS  PDU  network  packet)  was 
defined  and  populated.  The  8-bit  field  was  actually  set  aside  as  padding  in  earlier 
versions  of  DIS  however  the  meaning  of  this  (PDU  Protocol  Family)  field  and  the  field 
values  were  not  defined  until  IEEE  1278.1  DIS  Version  5. 
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The  values  that  can  populate  this  PDU  Protocol  Family  field  (the  family  of  PDU 
protocols  to  which  this  PDU  belongs)  are  shown  in  table  2  [27-28],  PDU  Type  values  of 
128  and  above  are  specified  as  experimental  and  may  be  application  specific.  The 
Protocol  Family  numbers  129  and  above  contain  these  experimental  PDUs.  The  130  to 
133  PDU  Family  values  are  experimental,  are  US  Navy  (BFTT)  specific  [28]  and  are  not 
specified  in  the  IEEE  documentation  [27], 


Table  2.  DIS  Protocol  Family  Numbers 


DIS  Protocol  Family  Number 

DIS  Protocol  Family 

0 

Other 

1 

Entity  Information/ Interaction 

2 

Warfare 

3 

Logistics 

4 

Radio  Communications 

5 

Simulation  Management 

6 

Distributed  Emission  Regeneration 

7 

Entity  Management 

8 

Minefield 

9 

Synthetic  Environment 

10 

Simulation  Management  with  Reliability 

11 

Live  Entity 

12 

Non-Real  Time 

129 

Experimental  -  Computer  Generated  Forces 

130 

Experimental  -  Entity  Information  -  Field  Instrumentation 

131 

Experimental  -  Warfare  Field  Instrumentation 

132 

Experimental  -  Environmental  Object  Information 

133 

Experimental  -  Entih/  Management 

4.2  DIS  Protocol  Families 

In  a  DIS  exercise  a  large  variety  of  entities  need  to  be  represented.  The  location  and 
orientation  is  critical  for  the  correct  representation  of  the  entity  by  other  simulations  on 
the  network.  Inclusion  of  the  entity  velocity  and  acceleration  parameters  allows 
receiving  simulations  to  (independently)  accurately  predict  entity  behaviour.  A 
simulation  may  also  be  required  to  accurately  model  the  appearance  of  an  entity.  All 
this  information  is  conveyed  through  the  DIS  Entity  Information/ Interaction  family 
Entity  State  PDU  (ESPDU). 


Warfare  in  a  DIS  exercise  involves  the  firing  and  detonation  of  munitions.  When  an 
entity  fires  a  weapon  the  location  of  the  firing  weapon  and  the  type  of  munition  fired 


9 


DSTOTR-1565 


needs  to  be  communicated  over  the  network.  The  Fire  PDU  and  the  Detonate  PDU  are 
members  of  the  DIS  Warfare  PDU  family. 

Representation  of  lasers,  active  electromagnetic  emissions,  and  acoustic  emissions 
including  active  counter-measures  are  essential  in  certain  simulation  exercises. 
Emitting  entities  simulate  their  emitter  and  output  real-time  operational  parameters. 
Receiving  entities  can  then  regenerate  the  transmitted  signal  based  upon  the  simulated 
emitter  output  data  and  stored  database.  Each  receiving  entity  is  responsible  for 
determining  if  the  emission  is  detectable.  If  detectable,  the  receiving  entity  will  use  the 
emission  data  to  appropriately  influence  its  detection  equipment  or  simulation  of  that 
equipment. 

DIS  exercise  management  is  also  desirable.  Individual  entities  within  a  simulation  need 
to  be  controllable  as  does  the  starting,  pausing,  restarting  and  stopping  of  simulation 
applications.  The  Exercise  Management  PDU  family  handles  exercise  management  in 
DIS. 

Radio  and  Intercom  communications  are  another  important  (and  expensive)  part  of  a 
simulator.  This  functionality  has  been  included  in  DIS  in  the  Radio  Communications 
PDU  family  to  allow  communications  interoperability  between  simulators, 

4.3  The  Entity  Information  /  Interaction  PDU  Family 

4.3.1  The  Entity  State  PDU 

The  Entity  State  PDU  (ESPDU)  communicates  information  about  an  entity's  state 
including  the  appearance  and  location  of  the  entity.  Also  included  is  state  information 
that  is  necessary  for  receiving  simulation  applications  to  represent  the  issuing  entity  in 
the  simulation  applications  own  simulation  [IEEE  1278.1  - 1995]. 

The  Entity  State  PDU  contains  the  following  information: 

a)  Identification  of  the  entity  that  issued  the  ESPDU 

b)  Identification  of  the  force  to  which  the  entity  belongs 

c)  The  entity  type  being  represented  by  the  ESPDU 

d)  Information  about  the  location  of  the  entity  in  the  simulated  world  including 
location,  velocity,  orientation  etc. 

e)  Dead  reckoning  algorithm  used 

f)  Additional  information  about  the  entity  including  appearance  (normal, 
smoking,  on  fire,  etc.),  markings,  articulated  parts  information,  etc. 

4.3.2  Dead  Reckoning 

Dead  reckoning  is  a  method  used  to  estimate  the  position  and/  or  orientation  of  an 
entity  based  on  a  previously  known  position  and/ or  orientation  and  estimates  of  time 
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and  motion.  Entity  State  PDUs  can  be  responsible  for  much  of  the  bandwidth  used  by  a 
simulator.  Dead  reckoning  is  used  to  reduce  the  rate  at  which  Entity  State  PDUs  are 
issued. 

Each  simulation  application  maintains  two  state  models  of  each  entity  it  is  representing 
in  support  of  the  dead  reckoning  process.  One  model  is  the  internal  model  used  by  the 
simulation  application  to  represent  its  entity.  The  other  model  is  the  dead  reckoning 
model  of  the  entity  it  is  representing.  Certain  thresholds  are  used  to  determine  if  the 
entity's  actual  position/ orientation  has  varied  an  allowable  amount  from  its  dead 
reckoned  position/  orientation.  When  the  entity's  actual  position/ orientation  has 
varied  from  the  dead  reckoned  position/ orientation  by  more  than  a  threshold  value, 
the  simulation  application  issues  an  Entity  State  PDU  to  communicate  the  entity's 
actual  position  and  orientation  to  other  simulation  applications.  The  simulation 
application  uses  the  same  information  communicated  to  other  simulation  applications 
to  update  its  dead  reckoning  model  of  its  entity.  Since  DIS  PDUs  are  broadcast  all  other 
simulation  applications  also  receive  the  updated  PDU. 

Each  simulation  application  maintains  a  dead  reckoning  model  of  the 
position/ orientation  of  entities  that  are  of  interest  (within  sight  or  range)  as  specified 
by  the  dead  reckoning  model  in  use.  When  the  simulation  application  receives  a  new 
update  from  one  of  the  entities  it  is  dead  reckoning,  it  corrects  its  dead  reckoning 
model  according  to  the  updated  position/ orientation,  velocity,  and  acceleration 
information.  Smoothing  techniques  may  be  used  to  eliminate  jumps  that  occur  in  a 
visual  display  when  the  dead  reckoning  position/ orientation  of  an  entity  is  corrected 
using  more  recent  position/  orientation  data. 

4.3.3  Issuing  And  Receiving  Entity  State  PDUs 
A  simulation  issues  an  Entity  State  PDU  when: 

a)  The  discrepancy  between  an  entity's  actual  state  (as  predicted  by  the  entity 
simulation's  own  internal  high-fidelity  model)  and  its  dead  reckoned  state 
exceeds  a  predetermined  threshold 

b)  The  entity's  appearance  changes 

c)  The  ESPDU's  dead  reckoning  algorithm  has  changed 

d)  The  predetermined  real-world  "Heart  Beat"  time  has  elapsed  since  the  last 
Entity  State  PDU  was  issued 

e)  The  entity  ceases  to  exist  in  the  synthetic  environment 

On  receipt  of  an  Entity  State  PDU  a  simulation  application  should  determine  whether 
the  entity  is  being  accurately  represented.  If  not  the  simulation  application  should  use 
die  information  contained  in  the  latest  Entity  State  PDU  to  remodel  the  position, 
orientation,  and  appearance  of  the  relevant  entity. 


11 


DSTO-TR-1565 


If  a  deactivated  appearance  ESPDU  is  received  or  if  a  predetermined  length  of  time  has 
elapsed  since  any  entity's  last  Entity  State  PDU  then  all  simulations  should  remove  that 
entity  from  the  exercise. 

4.3.4  The  Collision  PDU 

Throughout  a  simulation  exercise,  information  associated  with  the  interactions  that 
take  place  between  entities  needs  to  be  exchanged.  In  the  event  that  two  entities  collide 
(or  an  entity  collides  with  another  object  such  as  a  building  in  the  simulated  world)  the 
simulations  controlling  the  entities  must  be  informed  of  the  collision.  A  message  (the 
Collision  PDU)  about  the  collision  is  sent  by  each  simulation  application  when  it 
detects  that  its  entity  has  collided  with  another  entity.  Each  simulation  application 
determines  the  damage  to  its  own  entity  based  on  information  in  the  collision  message. 

The  Collision  PDU  contains  the  following  information: 

a)  Identification  of  the  entity  that  issued  the  PDU 

b)  Identification  of  the  other  entity  involved  in  the  collision 

c)  Collision  type 

d)  Collision  location  with  respect  to  entity  location,  and 

e)  Further  information  to  allow-  damage  determination 

4.4  The  Warfare  PDU  Family 

Weapons  effects  in  a  DIS  exercise  are  communicated  through  the  use  of  the  Warfare 
PDUs  -  the  Fire  PDU  and  the  Detonation  PDU. 

4.4.1  The  Fire  PDU 

The  Fire  PDU  is  issued  when  a  weapon  is  fired  and  contains  the  following  information: 

a)  Identification  of  the  entity  that  fired  the  weapon. 

b)  If  known  identification  of  the  intended  target  entity. 

c)  Identification  of  the  tracked  munition  fired, 

d)  Information  required  to  predict  the  path  and  impact  of  the  munition  such  as  the 
munition  launch  location,  munition,  warhead  and  fuse  types,  quantity  and  rate 
at  which  the  munition  was  fired,  initial  munition  velocity  and  range,  etc. 

If  simulation  entities  can  detect  and  react  to  the  munition  during  the  munition's  travel 
to  effect  the  outcome  of  the  simulation,  the  owmer  of  the  munition  must  immediately 
issue  an  Entity  State  PDU  describing  the  munition  (ie  the  munition  is  represented  as  an 
entity)  once  die  Fire  PDU  has  been  issued.  Otherwise  no  Entity  State  PDUs  need  be 
issued  for  the  munition. 
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On  receipt  of  a  Fire  PDU  a  simulation  application  can  use  the  Fire  PDU  information  to 
represent  any  (visual  and  aural)  effects  required  such  as  muzzle  flash,  noise,  smoke  etc. 

4.4.2  The  Detonation  PDU 

The  Detonation  PDU  is  normally  issued  by  the  same  simulation  application  that 
initially  generated  the  munition  or  its  firing.  The  Detonation  PDU  is  issued  when  a 
munition  impacts  or  detonates  and  contains  the  following  information: 

a)  Identification  of  the  entity  issuing  the  PDU. 

b)  Identification  of  the  target  entity  if  an  entity  has  been  impacted. 

c)  Identification  of  the  munition  being  detonated. 

d)  Information  required  to  represent  the  impact  or  detonation  of  the  munition 
including  location,  munition,  warhead  and  fuse  types,  quantity  and  rate  at 
which  the  munition  was  fired,  munition  detonation/impact  velocity,  target 
entity  detonation  location,  detonation  result,  etc. 

A  munition  may  impact  or  detonate  on  a  specific  entity,  on  a  specific  terrain  or  the 
munition  may  detonate  without  effecting  a  specific  entity  or  terrain. 

On  receipt  of  a  Detonation  PDU  a  simulation  application  can  use  the  information 
contained  within  this  PDU  to  represent  any  (visual  and  aural)  effects  that  may  be 
produced  by  the  detonation  or  impact  of  the  munition.  The  receiving  simulation 
application  can  also  use  the  information  contained  within  the  Detonation  PDU  to 
determine  damage  that  may  have  been  received  by  the  target  entity  as  a  result  of  the 
impact  or  detonation. 

If  the  munition  was  represented  as  an  entity  the  Detonation  PDU  must  be  followed  by 
a  final  munition  Entity  State  PDU  with  the  appearance  field  set  to  "Deactivated"  (ie 
Delete  Entity). 

4.4.3  Summary  for  the  Entity  Information/Interaction  and  Warfare  PDU 
Families 

The  Entity  State  PDU,  the  Fire  PDU  and  the  Detonation  PDU  are  the  fundamental  DIS 
simulation  PDUs.  The  Entity  State  PDU  distributes  the  basic  information 
(identification,  location,  velocity,  acceleration,  orientation,  etc.)  describing  the 
behaviour  of  an  entity .  The  Fire  and  Detonate  PDUs  describe  the  warfare  interactions 
of  entities  and  should  be  supported  by  all  simulators  because  these  PDUs  are  crucial 
from  an  After  Action  Review  Debriefing  point  of  view. 

Although  probably  not  strictly  required  for  an  air  domain  scenario,  the  Collision  PDU 
should  be  required  for  land  or  maritime  entity  scenarios  and  is  therefore  included  in 
the  recommended  set  of  PDUs. 
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4.5  The  (Core)  Simulation  Management  PDU  Family 

Simulation  Management  may  or  may  not  be  required  for  participation  in  an  exercise, 
depending  upon  the  requirements  of  each  exercise.  Any  computer  on  the  DIS  network 
may  perform  simulation  management.  An  exercise  may  have  one  such  Simulation 
Manager  (SM),  or  multiple  SMs.  Any  single  entity  may  interact  with  one  or  multiple 
Simulation  Managers  during  an  exercise,  or  none  at  all.  Functions  of  simulation 
management  include  starting,  restarting,  pausing,  and  stopping  of  an  exercise;  creating 
and  removing  entities  from  an  exercise;  and  collecting  and  distributing  data  with 
simulation  applications. 

4.5.1  The  Start  /  Resume  PDU 

The  Start/Resume  PDU  tells  a  simulation  (or  a  simulation  entity)  that  it  is  to  leave  a 
Stopped /Frozen  state  and  begin  participating  in  a  simulation  exercise. 

The  Start  /  Resume  PDU  contains  the  following  information: 

a)  The  identification  (Site,  Application,  and  Entity  Identifier  numbers)  of  the 
application  (entity)  from  which  the  Start  /  Resume  PDU  originated. 

b)  The  identification  of  the  application  (entity)  for  which  the  Start  /  Resume  PDU 
is  intended. 

c)  Real-World  Start  /  Resume  time. 

d)  Simulation  Start  /  Resume  time. 

e)  A  unique  Start  /Resume  Request  Identifier  code. 

4.5.2  The  Stop  /  Freeze  PDU 

The  Stop /Freeze  PDU  tells  a  simulation  (or  a  simulated  entity)  that  it  shall  leave  a 
Simulating  state  and  enter  a  Stopped/Frozen  state. 

The  Stop  /  Freeze  PDU  contains  the  following  information: 

a)  The  identification  (Site,  Application,  and  Entity  Identifier  numbers)  of  the 
application  (entity)  from  which  the  Stop  /  Freeze  PDU  originated. 

b)  The  identification  of  the  application  (entity)  for  which  the  Stop  /  Freeze  PDU  is 
intended. 

c)  Real-World  Stop  /  Freeze  time. 

d)  The  reason  the  simulation  or  entity  was  stopped  /  frozen. 

e)  The  Frozen  Behaviour  of  the  Stopped  /  Frozen  simulation  or  entity. 

f)  A  unique  Stop  /Freeze  Request  Identifier  code. 
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4.5.3  The  Acknowledge  PDU 

The  Acknowledge  PDU  is  issued  by  a  receiving  simulation  to  verify  to  tire  SM  that  the 
original  Start  /  Resume  or  Stop  /Freeze  PDU  was  received. 


The  Acknowledge  PDU  contains  the  following  information: 

a)  The  identification  (Site,  Application,  and  Entity  Identifier  numbers)  of  the 
application  (entity)  from  which  the  Acknowledge  PDU  originated. 

b)  The  identification  of  the  application  (entity)  for  which  the  Acknowledge  PDU  is 
intended. 

c)  An  Acknowledge  Flag  indicating  what  type  of  message  has  been 
acknowledged. 

d)  A  Response  Flag  indicating  whether  or  not  the  receiving  simulation  or  entity 
was  able  to  comply  with  the  request  and  for  what  reason. 

e)  A  matching  unique  Request  Identifier  code  to  that  received  in  the  original  Start 
/  Resume  or  Stop  /Freeze  PDU. 

4.5.4  The  Comment  PDU 

The  Comment  PDU  can  be  used  by  any  simulation  application  to  input  a  message  into 
the  DIS  data  stream  to  be  used  as  a  comment,  error  or  test  message  or  as  a  position 
marker  in  a  stored  DIS  data  log  file. 

The  Comment  PDU  contains  the  following  information: 

a)  The  identification  (Site,  Application,  and  Entity  Identifier  numbers)  of  the 
application  (entity)  from  which  the  Comment  PDU  originated. 

b)  The  identification  of  the  application  (entity)  for  which  the  Comment  PDU  is 
intended. 

c)  Fixed  and  /  or  variable  size  data  records. 

No  response  is  required  on  receipt  of  the  Comment  PDU. 

4.6  Other  (Core)  Simulation  Management  PDUs 

Simulation  management  PDU  functions  include:  starting,  restarting,  pausing,  and 
stopping  an  exercise;  the  creation  and  removal  of  entities  from  an  exercise;  and 
collection  and  distribution  of  data  with  simulation  applications. 

The  US  Navy  Battle  Force  Tactical  Training  (BFTT)  program  defines  a  Core  Set  of 
Simulation  Management  PDUs  [28]  needed  for  exercise  control  as  the  Start/Resume, 
Stop/Freeze,  Action  Request  Action  Response  and  Acknowledge  PDUs.  These  PDUs 
allow  simulations  to  transition  from  the  Stopped  State  to  the  Simulating  State  and  vice- 
versa.  'J 
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4.6.1  The  Action  Request  PDU 

The  Action  Request  PDU  is  used  by  the  SM  to  request  that  a  specific  action  be 
performed  by  a  simulation  entity.  Information  required  for  the  entity  to  perform  the 
requested  action  is  included  in  the  date  fields  of  this  PDU. 

The  Action  Request  PDU  contains  the  following  information: 

a)  The  identification  (Site,  Application,  and  Entity  Identifier  numbers)  of  the 
application  (entity)  from  which  the  Action  Request  PDU  originated 

b)  The  identification  of  the  application  (entity)  for  which  the  Action  Request  PDU 
is  intended. 

c)  A  Request  ID, 

d)  An  Action  ID. 

e)  Fixed  and  /  or  variable  size  date  records. 

Upon  receipt  of  the  Action  Request  PDU,  the  receiving  entity  sets  the  appropriate 
parameters  as  specified.  It  is  up  to  the  entity  receiving  the  Action  Request  PDU  to 
determine  which  (if  any)  parameters  described  in  the  Action  Request  PDU  it  can  set. 
The  receiving  entity  then  responds  with  an  Action  Response  PDU. 

4.6.2  The  Action  Response  PDU 

The  Action  Response  PDU  is  issued  on  receipt  of  an  Action  Request  PDU. 

On  receipt  of  the  Action  Response  PDU,  die  receiving  simulation  application  (the 
originator  of  the  Action  Request  PDU)  may  note  that  the  action  request  was  received 
and  the  status  of  that  request. 

4.6.3  The  Set  Data  PDU 

The  Set  Data  PDU  is  used  by  the  SM  to  set  or  change  certain  parameters  of  an  entity. 
The  Set  Date  PDU  contains  the  following  information: 

f)  The  identification  (Site,  Application,  and  Entity  Identifier  numbers)  of  the 
application  (entity)  from  which  the  Set  Date  PDU  originated 

g)  The  identification  of  the  application  (entity)  for  which  the  Set  Date  PDU  is 
intended. 

h)  Set  Date  Request  ID. 

i)  Fixed  and  /  or  variable  size  date  records. 

Upon  receipt  of  the  Set  Date  PDU,  the  receiving  entity  sets  the  appropriate  parameters 
as  specified  in  the  PDU.  It  is  up  to  the  receiving  entity  of  the  Set  Date  PDU  to 
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determine  which  (if  any)  parameters  described  in  tire  Set  Data  PDU  it  can  set.  The 
receiving  entity  then  responds  with  a  Data  PDU. 

4.6.4  The  Data  PDU 

A  Data  PDU  is  issued  in  response  to  a  Data  Query  PDU  or  a  Set  Data  PDU.  When  the 
Data  PDU  is  issued  in  response  to  the  Set  Data  PDU,  it  verifies  the  receipt  of  the  Set 
Data  PDU  by  returning  the  parameter  values  that  were  set  in  response  to  the  Set  Data 
PDU.  Parameters  that  were  set  in  the  simulation  to  the  same  values  as  in  the  Set  Data 
PDU  are  set  to  those  values  in  the  Data  PDU.  Parameter  values  that  were  set  to 
different  values  in  tire  simulation  than  requested  in  the  Set  Data  PDU  are  set  to  their 
actual  values  in  the  Data  PDU.  Parameters  to  which  tire  receiving  entity  cannot  comply 
are  not  included  in  the  Data  PDU  response. 

On  receipt  of  the  Data  PDU,  the  receiving  simulation  management  computer  may 
record  the  information  for  simulation  management  purposes. 

4.6.5  How  Are  the  Set  Data,  Data,  Action  Request  and  Action  Response  PDUs 
related? 


The  data  field  structure  of  the  Data  PDU  is  identical  to  the  Set  Data  PDU.  Once  the 
relevant  parameters  have  been  populated  as  required  to  the  Data  PDU  fields  the  only 
difference  between  the  Data  PDU  and  the  Set  Data  PDU  is  that  the  Originating  Entity 
ID  data  in  the  Set  Data  PDU  becomes  the  Receiving  Entity  ID  data  in  the  Data  PDU  and 
vice-versa. 

The  structure  of  the  Data  PDU  is  identical  to  the  Set  Data  PDU.  Therefore  once  the  Set 
Data  PDU  has  been  implemented  the  additional  cost  to  implement  the  Data  PDU 
should  be  small. 

The  data  field  structure  of  the  Action  Request  PDU  is  identical  to  the  Action  Response 
PDU.  Once  die  relevant  parameters  have  been  populated  as  required  to  the  Action 
Request  PDU  data  fields  the  only  difference  between  the  Action  Request  PDU  and  the 
Action  Response  PDU  is  that  the  Originating  Entity  ID  data  in  the  Action  Request  PDU 
becomes  the  Receiving  Entity  ID  data  in  the  Action  Response  PDU  and  vice-versa. 

The  data  field  structures  of  the  Set  Data/Data  PDUs  are  almost  identical  to  the  data 
field  structures  of  the  Action  Request/ Action  Response  PDUs.  The  field  size  bit 
patterns  and  the  locations  of  these  data  fields  in  the  PDUs  are  exactly  the  same  in  all 
four  PDUs.  The  only  difference  between  these  PDUs  is  that  an  unused  32-bit  padded 
field  in  the  Set  Data  and  Data  PDUs  becomes  a  32-bit  Action  ID  field  in  the  Action 
Request  and  Action  Response  PDUs. 

The  Action  Request  PDU  is  meant  to  be  used  to  request  that  a  specific  action  be  carried 
out  by  an  entity  in  a  simulation. 
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The  Set  Data  PDU  is  often  used  to  remotely  start  an  application  over  the  network.  The 
remotely  started  application  can  be  populated  with  data  via  the  Set  Data  PDU  fixed 
and/or  variable  sized  data  records. 

Tire  enumeration  values  used  in  the  Request  ID  field  in  the  Set  Data  PDU  can  be  used 
to  request  a  user-defined  action.  These  Request  ID  field  enumeration  values  have  not 
been  predefined  in  any  DIS  documentation.  The  specifically  targeted  applications  are 
supposed  to  understand  what  action  is  required.  The  USN  BFTT  (but  not  the  IEEE) 
documentation  indicates  that  "the  Data  PDU  shall  respond  with  all  zero's  in  the  Request  ID 
field  lohen  it  cannot  comply  to  a  Set  Data  PDU "  [28],  Therefore  any  non-zero  value  can  be 
used  in  the  Set  Data  PDU  and  Data  PDU  Request  ID  field. 

The  application  from  which  the  Set  Data  PDU  originates  can  be  designed  with  the 
capability  to  start  or  modify  tire  behaviour  of  remote  applications  without  having  any 
knowledge  of  what  functions  the  remote  applications  carry  out.  This  can  be  done  using 
configuration  files.  This  (very  useful)  capability  could  be  used  to  start  an  application 
(eg  a  DIS  Data  Logger)  on  a  particular  (remote)  computer  using  a  particular  port 
number  on  the  DIS  network  thus  simplifying  considerably  network  application 
configuration  management. 

The  Set  Data  PDU  could  also  be  used  to  modify  tire  behaviour  of  an  already  started 
application  (rewind/ replay  the  DIS  Data  Logger,  etc). 

In  another  example  a  simulation  application  could  start  in  a  normal  mode  but  be  reset 
to  an  alternate,  replay  mode  by  a  Set  Data  PDU  when  a  DIS  Data  Logger  replays 
recorded  DIS  data. 

In  normal  mode  a  simulator  application  could  broadcast  the  settings  or  values  of  dials 
or  gauges  by  sending  out  a  Set  Data  PDU  or  an  Action  Request  PDU  with  the  relevant 
dial  or  gauge  date  embedded  in  the  PDU  data  fields.  If  this  simulation  application  is 
(re)  set  to  a  replay  mode  (using  a  Set  Data  PDU)  the  simulator  could  set  these  dials  or 
gauges  to  the  values  specified  in  the  replayed  Set  Date  or  Action  Request  PDUs  and 
thus  DIS  could  be  used  to  record  and  replay  the  settings  of  such  dials  or  gauges.  DIS 
was  never  specifically  designed  with  this  capability  in  mind  however  it  can  be 
achieved  because  a  DIS  Date  Logger  should  record  all  DIS  PDUs  including  the  Set  Date 
and  Action  Request  PDUs  that  contain  the  dial  or  gauge  settings  and  the  interpretation 
of  the  information  stored  in  the  Set  Date  or  Action  Request  PDUs  is  left  up  to 
individual  simulation  application. 

Although  the  USN  BFTT  program  considers  the  Action  Request  PDU  and  the  Action 
Response  PDU  to  be  core  management  PDUs,  if  the  specific  entity  actions  supported  by 
these  PDUs  are  not  required  then  the  Action  Request  PDU  and  the  Action  Response 
PDU  are  not  necessary  and  the  Start/Resume/Stop/Freeze  capabilities  may  be  all  that 
is  required. 
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The  application  startup  and  modification  capabilities  of  the  Set  Data  and  Data  PDUs 
appear  to  be  very  useful  to  enable  remote  management  of  applications  over  tire 
network. 

4.6.6  Summary  for  the  Simulation  Management  PDU  Family 

Simulation  applications  should  be  able  to  be  managed  in  a  DIS  exercise  with  many 
participants.  Not  all  simulation  applications  should  need  to  be  able  to  function  as 
Simulation  Managers.  Therefore  all  simulation  applications  should  support  tire 
reception  of  (and  appropriate  reaction  to)  the  Start/Resume  and  Stop/Freeze  PDUs 
and  transmit  the  required  response  Acknowledge  PDU. 

The  Comment  PDU  is  a  fundamental  PDU  from  an  After  Action  Review  Debrief  point 
of  view. 

The  Set  Data,  Data,  Action  Request  and  Action  Response  PDUs  are  not  considered  as 
fundamental  in  providing  interoperability  with  other  DIS  simulators.  They  are 
however,  potentially,  useful  PDUs  in  enhancing  the  record  and  replay  capability  of  a 
simulator  and  the  ability  of  a  simulation  application  to  remotely  start,  stop  and  modify 
the  behaviour  of  other  applications  in  ways  that  DIS  was  never  specifically  designed  to 
do.  Each  individual  simulator  should  carefully  examine  the  usefulness  of  these  PDUs. 

4.7  The  Distributed  Emission  Regeneration  PDU  Family 

4.7.1  The  Electromagnetic  Emission  PDU 

The  Electromagnetic  Emission  PDU  is  used  to  communicate  active  electronic  warfare 
emissions  and  countermeasures.  Radio  communications  and  designator  tracking  are 
handled  by  separate  PDUs. 

The  Electromagnetic  Emission  PDU  contains  the  following  information: 

a)  Identification  of  the  emitting  entity. 

b)  Number  of  emitter  systems  for  which  information  is  being  provided. 

c)  For  each  emitter  system  the  relative  emitter-entity  location,  the  number  of 
beams,  the  emitter  name,  function,  identification  number,  frequency,  frequency 
range,  power,  pulse  repetition  frequency,  pulse  width,  and  additional  beam 
and  track/ jamming  parameters  are  provided. 

On  receipt  of  an  Electromagnetic  Emission  PDU  the  receiving  simulation  application 
determines  if  the  emission  is  detectable  and  uses  the  information  in  the  PDU  to 
determine  the  behaviour  of  tire  emission  detection  (eg  electronic  warfare)  equipment 
controlled  by  that  simulation  application. 
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4.7.2  The  EFF /  ATC/N AVAIDS  PDU 

The  IFF  /  ATC/NAVAIDS  PDU  includes  the  following  information: 

a)  Identification  of  the  entity  emitting  the  IFF/  ATC/NAVAIDS  signals. 

b)  Identification  of  the  type  of  system  emitting  the  signals. 

c)  The  status  of  the  emitting  system. 

d)  Which  modes  of  signals  the  system  is  capable  of  emitting  and  the  codes 
transmitted  for  these  modes. 

Additional  optional,  IFF/ ATC/NAVAIDS  PDU  information  layers  can  convey 
information  regarding: 

a)  The  electromagnetic  characteristics  of  a  typical  emission  -  power,  frequency, 
pulse  width  etc. 

b)  The  rate  at  which  signals  are  emitted. 

c)  Identification  of  which  signals  are  responses  to  which  previous  signals. 

The  receiving  simulation  is  responsible  for  determining  if  the  IFF/ ATC/NAVAIDS 
information  is  detectable, 

4.7.3  Summary  for  the  Distributed  Emission  Regeneration  PDU  Family 

Within  the  next  5  years  most,  if  not  all,  ADF  platforms  of  significance  will  have  an 
Electronic  Warfare  capability  and  therefore  support  for  the  Distributed  Emission 
Regeneration  Family  PDUs  should  be  considered  as  essential. 

However  the  fact  that  the  USN  Battle  Fleet  Tactical  Training  project  and  the  RAN  FFG 
Upgrade  Project  have  both  added  extra  experimental  Electromagnetic  Emission  PDUs 
indicates  that  the  IEEE  1278.1a  standard  may  not  fully  support  a  modem  Electronic 
Warfare  capability. 

4.8  The  Radio  Communications  PDU  Family 

4.8.1  The  Transmitter  PDU 

The  Transmitter  PDU  is  used  to  communicate  the  state  of  a  radio  transmitter. 

The  Transmitter  PDU  includes  the  following  information: 

a)  The  identification  of  the  entity  that  contains  the  radio  transmitter 

b)  The  identification  of  the  particular  transmitter  (and  its  type)  being  described 

c)  State  of  the  transmitter  (such  as  off,  on  but  not  transmitting  or  on  and 
transmitting) 

d)  Source  of  radio  input  (pilot,  co-pilot,  etc.) 
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e)  Absolute  and  relative  radio  antenna  location 

f)  Radio  transmitter  parameters  such  as  frequency,  bandwidth,  power, 
modulation,  etc. 

g)  Secure  communications  parameters  such  as  equipment  type  and  cryptographic 
key. 

A  Transmitter  PDU  is  issued  by  the  radio  transmitter  simulation  application  when: 

a)  A  predetermined  (heart  beat)  length  of  time  has  elapsed  since  issuing  the  last 
Transmitter  PDU 

b)  A  relevant  parameter  has  changed  or  exceeded  a  required  threshold 

When  a  transmission  is  initiated,  a  Transmitter  PDU  is  issued  before  the  first  Signal 
PDU  of  the  transmission.  When  a  transmission  is  concluded,  a  Transmitter  PDU  will 
follow  the  final  Signal  PDU  of  the  transmission. 

On  receipt  of  a  Transmitter  PDU  the  receiving  radio  simulation  application  determines 
what,  if  any,  special  effects  (no  reception,  clear  reception,  level  of  noise  or  jamming 
etc.)  are  applied  to  the  received  radio  transmission  signal.  If  the  transmission  is  to  be 
received  and  demodulated  the  receiving  radio  simulation  application  must  then  start 
to  process  the  data  in  any  Signal  PDUs  received  from  that  particular  radio  transmitter  - 
see  below. 

4.8.2  The  Signal  PDU 

The  Signal  PDU  contains  the  content  of  a  radio  transmission.  This  content  may  be 
digitised  audio  or  other  data. 

The  Signal  PDU  contains  the  following  information: 

a)  Identification  of  the  entity  that  is  the  source  of  the  transmission 

b)  Identification  of  the  particular  transmitter  that  is  transmitting 

c)  The  encoding  scheme  used 

d)  The  type  of  signal  message  transmitted  (digitised  voice.  Link  11,  Link  16  etc.) 

e)  The  sample  rate 

f)  The  actual  digitised  voice  or  TDL  data 

For  voice  or  TDL  data  as  soon  as  a  transmitter  is  turned  on  (so  that  a  Transmitter  PDU 
with  a  state  of  on  and  transmitting  is  issued)  a  constant  stream  of  Signal  PDUs  is  issued 
to  enable  an  uninterrupted  flow  of  signal  content. 


On  receipt  of  a  Signal  PDU  the  receiving  application  determines  if  it  has  received  an 
associated  Transmitter  PDU.  If  the  correct  Transmitter  PDU  was  received  and  the 
receiving  simulation  application  determines  that  it  can  detect  the  transmission  the 
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receiving  simulation  application  converts  the  digitized  data  and  applies  any  special 
effects  required. 

4.8.3  The  Receiver  PDU 

The  Receiver  PDU  is  used  to  communicate  the  state  of  a  particular  radio  receiver  and  it 
contains  the  following  information: 

a)  The  identification  of  die  entity  controlling  the  radio  receiver  being  described 

b)  The  identification  of  the  particular  radio  receiver  that  is  being  described 

c)  The  state  of  die  receiver 

d)  The  identification  of  the  entity  that  is  the  source  of  the  radio  tiansmission 

e)  The  identification  of  the  particular  radio  at  the  source  of  the  radio  transmission 

A  Receiver  PDU  is  issued  by  the  radio  receiver  simulation  application  when: 

a)  A  predetermined  (heart  beat)  length  of  time  has  elapsed  since  issuing  the  last 
Receiver  PDU 

b)  A  relevant  parameter  has  changed  or  exceeded  a  required  threshold 
No  response  to  a  Receiver  PDU  is  required. 

4.8.4  Summary  for  the  Radio  Communications  PDU  Family 

For  simulators  the  DIS  Radio  Communications  PDU  Family  enables  radio 
communications  interoperability  between  simulators.  Other  than  the  IEEE  1278.1/la 
Radio  Communications  Family  PDUs  no  standard  exists  for  simulator 
communications. 

In  ADF  simulators  only  the  RAN  FFG  Upgrade  simulator  and  the  RAAF  ADGESIM 
simulator  have  provided  (will  provide)  DIS  Communications  at  installation.  A  DIS 
Communication  capability  has  now  been  added  to  the  HMAS  Watson  I0TTF  and 
CSTT  simulators  and  this  has  enabled  DIS  Communications  interoperability  between 
the  various  RAN  and  USN  systems  during  CReaMS  exercises  [22]. 

Overseas  most,  if  not  all,  simulators  provide  DIS  Communications  via  the  use  of 
proprietary  ASTi  [29]  hardware.  Intercom  PDUs  were  introduced  in  DIS  version  6 
(1278,1a);  however  before  the  introduction  of  this  version  of  DIS,  ASTi  assigned  all 
frequencies  below  100,000  Hz  as  intercom  channels.  In  the  exercises  the  author  has 
been  involved  in,  DIS  version  6  Intercom  PDUs  are  not  normally  used  so  as  to  enable 
support  of  legacy  DIS  (version  5)  communications  systems. 

Although  the  Signal  PDU  was  originally  designed  to  support  Link,  Link  enumerations 
were  not  available  until  2003.  By  this  time  major  simulation  projects  implement  Link 
by  sending  real  Link  messages  around  a  simulation  network  wrapped  up  in  the  NATO 
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standard  STANAG  SIMPLE  protocol.  These  Link  messages  are  wrapped  and 
unwrapped  as  required  and  are  used  as  input  to  real  Link  devices.  This  is  discussed  in 
more  detail  in  Appendix  A. 

DIS  Communications  Family  PDU  support  in  ADF  DIS  simulators  is  considered 
essential. 


5.  ADF  Simulator  DIS  Interoperability 


The  following  ADF  training  simulators  currently  (or  will  shortly)  have  a  DIS 
interoperability  capability: 

Table  3.  ADF  DIS  Capable  Simulators 


System 

DIS  Interface  Details 

RAN  HMAS  Watson  IOTTF  (FFG) 

IEEE  1278.1a 

RAN  HMAS  Watson  CSTT  (Anzac) 

IEEE  1278.1a 

RAN  FFG  UP 

IEEE  1278.1a 
(Including  Experimental) 

RAN  Seasprite 

IEEE  1278.1a 
(Including  Experimental) 

RAAF  AP-3C  OMS 

DIS  Version  3  or  4  ? 
IST-CR-93-40  (7  March  1994) 

RAAF  ADGESIM 

IEEE  1278.1a 

5.1  The  RAN  HMAS  Watson  IOTTF  Simulator 

From  a  DIS  Interface  perspective  the  HMAS  Watson  Integrated  Operations  Team 
Training  Facility  (IOTTF),  that  is  used  as  an  FFG  (its  DDG  model  is  no  longer  required) 
Team  Trainer,  is  comprised  of  three  DIS  components  over  two  networks.  The  two 
networks  are  the  DIS  Data  LAN  and  the  DIS  Radio  LAN.  The  IOTTF  Ship  model  is 
connected  to  the  DIS  Data  LAN  via  the  IOTTF  DIS  Gateway  (G/W),  the  ASTi  DIS 
Communications  System  (DAC)  is  connected  to  the  Radio  LAN  and  the  IOTTF  Exercise 
Management  Console  (EMC)  is  connected  to  both  LANs. 

The  HMAS  Watson  IOTTF  simulator  is  an  emulated  system.  Real  "ship-fit"  equipment 
is  not  used. 

The  DIS  PDUs  supported  by  each  of  these  IOTTF  components  (DIS  applications)  are 
shown  in  Table  4.  All  IOTTF  PDUs  supported  comply  with  the  IEEE  1278.1a  (DIS 
Version  6)  DIS  protocol  standard  [26].  A  simulator  can  respond  appropriately  or 
completely  ignore  a  PDU  received  from  the  network.  This  (Receive)  interaction  is 
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shown  in  the  Rx  column  in  Table  4.  A  simulator  can  convey  the  state  of  a  particular 
internal  interaction  by  transmitting  PDUs  onto  the  DIS  network  as  shown  in  the  Tx 
(Transmit)  column  in  Table  4. 


Table  4.  DIS  PDUs  Supported  in  each  IOTTF  DIS  Simulator  Component 


PDU 

Type 

PDU  Name 

Rx 

G/W 

Tx 

G/W 

Rx 

EMC 

Tx 

EMC 

Rx 

DAC 

Tx 

DAC 

Entity  State 

✓ 

✓ 

✓ 

X 

X 

X 

2 

Fire 

X 

✓ 

✓ 

X 

X 

X 

3 

Detonation 

X 

✓ 

✓ 

X 

X 

X 

4 

Collision 

✓ 

✓ 

✓ 

X 

X 

X 

11 

Create  Entity 

X 

X 

✓ 

✓ 

X 

X 

12 

Remove  Entity 

X 

X 

✓ 

✓ 

X 

X 

13 

Start/ Resume 

X 

X 

✓ 

✓ 

X 

X 

14 

Stop  /Freeze 

X 

X 

✓ 

✓ 

X 

X 

15 

Acknowledge 

X 

X 

✓ 

✓ 

X 

X 

20 

Data  1) 

✓ 

✓ 

✓ 

✓ 

X 

X 

22 

Comment 

X 

X 

✓ 

✓ 

X 

X 

23 

✓ 

✓ 

✓ 

X 

X 

X 

25 

X 

X 

✓ 

X 

✓ 

✓ 

26 

Signal 

X 

X 

X 

X 

✓ 

✓ 

27 

Receiver 

X 

X 

✓ 

X 

✓ 

✓ 

28 

✓ 

✓ 

✓ 

X 

X 

X 

41 

lafflJFW  iiukiyi±a^. JK 

✓ 

✓ 

X 

X 

X 

X 

51 

Create  Entity  -  R 

X 

X 

✓ 

✓ 

X 

X 

52 

X 

X 

✓ 

✓ 

X 

X 

53 

Start/ Resume  -  R 

X 

X 

✓ 

✓ 

X 

X 

54 

Stop  Freeze  -  R 

X 

X 

✓ 

✓ 

X 

X 

55 

Acknowledge  -  R 

X 

X 

✓ 

✓ 

X 

X 

62 

Comment  -  R 

X 

X 

✓ 

✓ 

X 

X 

66 

Collision  Elastic 

✓ 

✓ 

✓ 

X 

X 

X 

67 

Entity  State  Update 

✓ 

✓ 

✓ 

X 

X 

X 

1)  For  internal  communications  only 

5.2  The  RAN  HMAS  Watson  CSTT  Simulator 

The  DIS  PDUs  supported  by  the  HMAS  Watson  Anzac  Combat  System  Tactical  Trainer 
(CSTT)  are  shown  below  in  Table  5  where  b  is  for  internal  communications  only.  All 
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Table  5.  DIS  PDUs  Supported  in  the  Anzac  Ship  CSTT  simulator 


PDU  Type 

PDU  Name 

Receive 

Transmit 

1 

Entity  State 

✓ 

✓ 

2 

Fire 

X 

✓ 

3 

Detonation 

✓ 

✓ 

4 

Collision 

X 

✓ 

11 

Create  Entity 

✓  D 

X 

12 

Remove  Entity 

✓  9 

X 

13 

Start/Resume 

✓ 

✓ 

14 

Stop/Freeze 

✓ 

✓ 

15 

Acknowledge 

✓  9 

✓ 

20 

Data 

✓ 

X 

21 

Event  Report 

✓ 

X 

22 

Comment 

✓  9 

X 

23 

Electromagnetic  Emission 

✓ 

✓ 

25 

Transmitter 

✓ 

✓ 

26 

Signal 

✓ 

✓ 

27 

Receiver 

✓ 

✓ 

28 

IFF/ ATC/NAV  AIDS 

✓ 

✓ 

29 

Underwater  Acoustic 

✓  9 

✓ 

31 

Intercom  Signal 

✓ 

✓ 

41 

Environmental  Process 

✓  9 

X 

51 

Create  Entity  -  R 

✓  9 

X 

52 

Remove  Entity  -  R 

✓  9 

X 

53 

Start/Resume  -  R 

✓  9 

X 

54 

Stop  Freeze  -  R 

✓  9 

X 

55 

Acknowledge  -  R 

✓  9 

✓ 

56 

Action  Request  -  R 

✓  9 

X 

57 

Action  Response  -  R 

✓  9 

✓ 

58 

Data  Query  -  R 

✓  9 

X 

59 

Set  Data  -  R 

✓  9 

X 

60 

Data  -  R 

✓  9 

X 

61 

Event  Report  -  R 

✓  9 

X 

62 

Comment  -  R 

✓  9 

X 

63 

Record  Query  -  R 

✓  9 

X 

64 

Set  Record  -  R 

✓  9 

X 

65 

Record  - R 

✓  9 

✓ 

The  HMAS  Watson  CSTT  Anzac  ship  simulator  is  a  " ship-fit”  stimulated  system  that 
uses  actual  hardware  present  on  the  Anzac  platforms. 
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5.3  The  RAN  FFG  UP  Simulator 

The  RAN  FFG  UP  simulator  is  made  up  of  three  different  systems.  The  Garden  Island 
FFG  Land  Based  Test  System  (FFG  LBTS)  is  the  developmental  system  for  the  real  FFG 
On-Board  Training  System  (FFG  OBTS).  The  FFG  Tactical  Trainer  (FFG  TT)  system  is 
the  (stimulated)  training  simulator  to  be  located  at  the  Maritime  Warfare  Training 
Centre  at  the  HMAS  Watson  in  Sydney. 

As  part  of  the  Battle  Force  Tactical  Training  System,  the  US  Navy  is  currently  installing 
new  technology  combat  systems  in  all  of  its  major  platforms.  A  complete  shipboard 
system  is  constructed  by  selecting  the  required,  common.  Combat  System  (radars,  IFF, 
weapons,  navigation.  Data  Links,  Electronic  Warfare,  communications,  etc.) 
components  supporting  the  hardware  used  on  the  ship.  This  approach  is  very  similar 
to  the  COTS  plug  and  play  modular  approach  used  for  commodity  desktop  personal 
computers.  These  common  components  are  completely  independent  of  any  ship  type 
or  class. 

Training  capabilities  may  be  added  to  any  ship  (system)  at  any  time  by  simply  adding 
a  simulator  or  stimulator  to  the  Qn-Board  Training  network,  A  ship  (system)  may  train 
in  stand-alone  mode  in  a  common  synthetic  environment,  connect  to  other  ships,  joint 
or  coalition  platforms  meeting  the  required  interoperability  standards.  Combat  system 
operators  may  be  trained  individually  or  as  a  team. 

These  common,  USN,  BFTT  Combat  System  components  use  BFTT  (mostly  IEEE)  DIS 
PDUs  as  their  backbone  communication  protocols.  The  USN  has  its  own  BFTT  DIS 
standard  [28].  The  BFTT  standard  includes  all  the  IEEE  1278.1a  standard  PDUs  [26], 
There  are  however  extra  experimental  PDUs  and  some  non-IEEE  standard  PDUs  (eg  a 
version  5  IFF  PDU).  As  long  as  the  non-IEEE  standard  PDUs  are  not  used,  real  BFTT, 
ship  combat  (On-Board  Training)  systems  are  IEEE  DIS  compliant.  The  BFTT 
Enumerations  (DIS  PDU  data  field  values)  may  be  different  from  (and  possibly 
incompatible  with)  the  SISO  Enumerations  [27-28]. 

A  high  fidelity  (shore  based),  stimulated  training  system  (simulator)  can  be  easily 
constructed  from  a  set  of  these  common,  combat  system  components. 

These  simulator  components  are  exactly  the  same  as  those  used  on  a  ship  and  therefore 
behave  and  interoperate  correctly  -  they  are  high  fidelity  stimulated  components. 
Where  a  stimulator  system  is  not  available,  an  emulation  approach  can  be  used.  The 
actual  set  of  common  components  used  will  reflect  the  systems  for  which  the  training 
is  required.  A  diagram  of  the  USN  BFTT  Architecture  is  shown  in  Figure  1. 
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3D  Air  Radar.  IFF 
Stimulator  „ 


2D  Air  Radar,  IFF 
Stimulator 


Scenario 

Controller 


Comm/Data 

Simulator 


R  Fire  Control 
Radar  Stimulator 


ON-BOARD 
COMBAT  SYSTEMS 
TRAINING 


Train  on  any  ship 
" Train  Like  You  Fight 


LOCAL  AREA 
DIS  NETWORK 


Navigation 

Stimulator 


Common 

Components 


ON-BOARD 

TRAINERS 

Rack  Mount  or 
Portable  Configurations 
Available 


Personality  Modules  configure  an  OBT  to  meet  training  needs. 

Radars  -  Surface  Search,  2D  Air  Search,  BD  Air  Search,  Fire  Control 
Video  -  Simulated  Surface  or  Air  Search  Radar  (optional) 

IFF  -  Modes  1,  2,  3/A,  C,  4 

Weapons  -  Harpoon,  Sea  Sparrow,  SM-1,  MK-45  Cun,  MK-75  Gun,  ASROC 
Navigation  -  WSN-2,  WSN-5,  WSN-7,  Speed  Logs 
Data  Links  -  Link  11,  Link  4A 
EW  —  SLQ-32,  SRBOC 


Figure  1.  USN  BFTT  Architecture 


The  FFG  Upgrade  project  uses  a  more  modern  version  of  the  technology  used  in  the 
USN  BFTT  program.  The  same  USA  AAI  Corporation  [30]  is  working  on  both  the  BFTT 
and  FFG  UP  projects. 

The  DIS  PDUs  supported  by  the  RAN  FFG  UP  Project  are  shown  below  in  Table  6.  The 
IEEE  1278.1a  (DIS  Version  6)  DIS  Protocol  Standard  has  allowance  for  PDU  types  up  to 
127  (those  that  already  exist)  as  standardised  pre-defined  PDUs.  PDU  type  values  129 
and  above  are  reserved  and  can  be  used  by  projects  for  their  own  purposes.  The  FFG 
UP  Project,  private,  experimental  PDUs  are  also  shown  in  Table  6. 
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Table  6.  DIS  PDUs  Supported  in  the  FFG  UP  Simulator 


PDU  Type 

PDU  Name 

Receive 

Transmit 

1 

Entity  State 

✓ 

✓ 

2 

Fire 

X 

✓ 

3 

Detonation 

✓ 

✓ 

4 

Collision 

✓ 

✓ 

13 

Start/Resume 

✓ 

✓ 

14 

Stop/Freeze 

✓ 

✓ 

15 

Acknowledge 

✓ 

✓ 

18 

Data  Query 

✓  u 

✓  9 

19 

Set  Data 

✓  9 

✓  9 

20 

Data 

✓ 

X 

22 

Comment 

✓  9 

✓  9 

23 

Electromagnetic  Emission 

✓ 

✓ 

25 

Transmitter 

✓ 

✓ 

26 

Signal 

✓ 

✓ 

27 

Receiver 

✓ 

✓ 

28 

IFF/ ATC/NAV  AIDS 

✓ 

✓ 

29 

Underwater  Acoustic 

✓ 

✓ 

220 

Underwater  Environment 

✓ 

✓ 

221 

RAN  FFG  UP  Chaff 

✓ 

✓ 

230 

BFTT  Surface  Ship  Status  (S4) 

✓  D 

✓  9 

231 

BFTT  Chaff 

✓ 

✓ 

232 

BFTT  Environment 

✓ 

✓ 

233 

BFTT  Jammer 

✓ 

✓ 

235 

BFTT  Supplemental  Electromagnetic  Emission  (SEE) 

✓ 

✓ 

240 

RAN  FFG  UP  Trainer  Status 

✓  9 

✓  9 

241 

RAN  FFG  UP  Fused  Track 

✓  9 

✓  9 

tbd 

RAN  FFG  UP  Electromagnetic  Emission 

✓ 

✓ 

tbd 

RAN  FFG  UP  Link-11  /  Link-16 

tbd 

tbd 

1)  For  internal  communications  only 

5.4  The  RAAF  AP-3C  OMS  Simulator 

The  DIS  PDUs  supported  in  the  RAAF  AP-3C  Operational  Mission  System  (OMS) 
simulator  are  shown  in  Table  7  [31]. 

According  to  the  documentation  available  [31]  the  AP-3C  OMS  DIS  PDUs  are 
compliant  with  "Standard  for  Distributed  Interactive  Simulation  -  Application 
Protocols,  Version  3.0  Working  Draft,  IST-CR-93-40,  7  March,  1994". 
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Table  7.  DIS  PDUs  Supported  in  the  BAAF  AP-3C  OMS  Simulator 


PDU  Type 

PDU  Name 

Supported 

1 

Entity  State 

✓ 

2 

Fire 

✓ 

3 

Detonation 

✓ 

4 

Collision 

✓ 

13 

Start/ Resume 

✓ 

14 

Stop/Freeze 

✓ 

15 

Acknowledge 

✓ 

23 

Electromagnetic  Emission 

✓ 

? 

Acoustic  (?) 

✓ 

Table  8  shows  the  1ST  (Institute  for  Simulation  and  Training)  Report  Numbers  for  DIS 
Versions  3  and  4  Standards  Documentation. 

Table  8. 1ST  Report  Numbers  for  DIS  Versions  3  and  4  Standards  Documentation 


DIS  Version  Number 

DIS  Version 

1ST  Report  Number 

3 

DIS  2.0.3  (May  28, 1993) 

IST-CR-93-15 

4 

DIS  2.0.4  (March  16, 1994) 

IST-CR-94-50 

The  DIS  PDUs  in  the  AP-3C  OMS  simulator  may  have  been  developed  using  a  set  of 
documentation  published  prior  to  the  IEEE  standardisation  process  and  some  PDUs 
may  not  be  IEEE  compliant. 


According  to  the  AP-3C  BAE  documentation: 

"The  Acoustic  PDU  communicates  acoustic  information  and  sonar  system 
characteristics.  This  is  a  CAE  PDU  implemented  in  addition  to  the  DIS  standard,  it  is  a 
CAE  standard  PDU  and  is  used  to  inform  the  simulations  of  the  acoustics  and  sonar 
system  characteristics  data  of  all  surface  and  subsurface  players  in  the  scenario.  If  an 
external  simulator  does  not  use  this  PDU  then  it  will  be  ignored  [31]." 

There  is  no  (Underwater)  Acoustic  PDU  in  IEEE  DIS  Version  3  or  4.  The  Underwater 
Acoustic  PDU  first  appeared  in  the  1998  IEEE  1278.1a  DIS  Version  6  standard. 

5.5  The  RAAF  VAE  ADGESIM  Simulator 

The  RAAF  Virtual  Air  Environment  Air  Defence  Ground  Environment  Simulator 
(ADGESIM)  [8-9]  is  used  at  RAAF  Williamtown  and  RAAF  Darwin  to  train  Air 
Defence  Controllers.  ADGESIM  was  developed  by  DSTO  after  industry  could  not 
deliver  a  suitable  capability  within  a  suitable  time  frame. 
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ADGESIM  uses  an  architecture  similar  to  that  used  in  the  US  Navy's  BFTT  Project  and 
the  Australian  Navy's  FFG  Upgrade  Project.  All  ADGESIM  components  interoperate 
on  a  DIS  network  and  the  PDUs  (the  backbone  communications  protocol  packets)  from 
the  DIS  network  are  used  to  stimulate  real  system  components.  ADGESIM  is  a  high 
fidelity,  stimulated  system  and  Air  Defence  Controllers  report  that  they  cannot 
differentiate  between  the  behaviour  of  the  training  system  and  the  behaviour  of  the 
real  system. 

ADGESIM  (and  its  components)  support  a  basic  set  of  PDUs  necessary  to  achieve  the 
required  Air  Defence  Controller  training  outcomes.  The  DIS  PDUs  supported  in  the 
RAAF  ADGESIM  simulator  are  shown  in  Table  9.  Not  all  ADGESIM  components 
support  all  the  PDUs  listed  in  table  9  and  the  various  PDU  types  are  being 
implemented  as  they  are  required,  and  when  time  permits,  in  the  various  ADGESIM 
components. 

Table  9.  DIS  PDUs  Supported  in  the  DSTO  RAAF  ADGESIM  Simulator 


PDU  Type 

PDU  Name 

Supported 

1 

Entity  State 

✓ 

2 

Fire 

✓ 

3 

Detonation 

✓ 

19 

Set  Data 

✓ 

23 

Electromagnetic  Emission 

✓ 

25 

Transmitter 

✓ 

26 

Signal 

✓ 

27 

Receiver 

✓ 

28 

IFF 

✓ 

The  BFTT  and  FFG  UP  Projects  use  a  common  component,  reconfigurable,  COTS,  plug 
and  play  modular  approach.  Although  these  common  components  are  COTS,  they  will 
mostly  still  comprise,  or  be  built  upon,  proprietary  software  and  hardware. 

The  ADGESIM  simulator  takes  this  approach  further.  As  well  as  using  the  IEEE  DIS 
PDUs  as  the  backbone  communication  protocols,  all  ADGESIM  components  are 
software  only  applications  (they  require  no  specialist  hardware  eg,  ship  fit  consoles), 
run  on  commodity  personal  computer  hardware  and  software  (Microsoft  Windows  XP 
Pro),  and  are  developed  using  the  latest  version,  industry  standard  Microsoft  (Visual 
Studio.NET  2003)  C++  compiler. 

A  diagram  of  the  ADGESIM  architecture  is  shown  in  Figure  2. 
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Figure  2.  RAAF  VAE  ADGESIM  Simulator  Architecture 


All  ADGESIM  components  are  reusable,  that  is,  they  can  be  used  on  other  (ADF)  DIS 
compliant  simulators  without  (or  with  very  little)  modification  because,  unlike  the 
more  recent  Higher  Level  Architecture  (see  detailed  discussion  in  section  7),  the 
underlying  backbone  communication  DIS  PDU  data  structures  [25-26]  and  the  data 
contained  within  the  DIS  PDUs  [27]  have  been  standardised  by  the  IEEE. 


ADGESIM  is  low  cost  to  purchase,  cost  effective  to  develop  and  maintain,  is  high 
fidelity  and,  if  required  because  it  runs  on  commodity  hardware  and  software,  will  be 
long  lived.  This  low  cost,  cost  effective,  stimulated  and  long-lived  simulator 
philosophy  and  approach  will  the  subject  of  a  separate  report  [32], 


6.  The  Recommended,  Minimum,  Basic  Set  of  DIS 
PDUs  for  a  Simulator 


The  objective  of  having  a  recommended,  minimum,  basic  set  of  DIS  PDUs  for  a 
simulator  is: 


31 


DSTO-TR-1565 


a)  To  reduce  the  analysis  phase  to  determine  what  PDUs  are  required  for  any 
simulator,  and 

b)  To  ensure  that  every  ADF  simulator  implements  a  minimum  set  of  DIS  PDUs  to 
allow  sufficient  application  protocol  interoperability  to  enable  that  simulator  to 
participate  in  a  DIS  Wide  Area  Network  training  exercise  at  the  time  the 
simulator  is  accepted  by  the  Commonwealth  without  an  expensive,  after 
acceptance  (eg  Engineering  Change  Proposal  (ECP)),  modification  thus 
reducing  cost  and  risk  to  the  simulator  project  (ie  the  Commonwealth). 

During  the  simulator  design  phase,  an  analysis  of  the  platform's  capabilities  should  be 
carried  out  to  determine  the  capabilities  and  DIS  PDUs  necessary  to  meet  the  training 
outcomes  required.  However  most  military  simulators  should  have  a  minimum  basic 
set  of  DIS  PDUs  to  provide  a  sufficient  level  of  application  protocol  interoperability,  to 
ensure  that  it  can  participate  in  a  DIS,  Wide  Area  Network,  training  exercise. 

The  type  of  simulator  requiring  this  minimum,  basic  set  of  DIS  PDUs  is  assumed  to 
simulate  a  platform  that  can  carry  weapons,  have  an  electronic  warfare  capability  and 
require  radio/ intercom  communications.  A  single  engine  Cessna  may  not  carry  any 
weapons  and  may  have  no  electronic  warfare  capability. 

Comparing  the  DIS  PDUs  supported  by  major  platform  simulators  will  give  an 
indication  of  such  a  common  set  of  PDUs  -  this  is  done  in  Section  6.1  below. 


Analysing  the  recorded  DIS  PDU  traffic  from  a  major  (coalition)  exercise  should  also 
give  an  indication  of  such  a  common  set  of  PDUs  -  this  is  discussed  in  Section  6.2. 

The  results  of  these  two  alternative  methods  are  combined  in  section  6.3  that  presents  a 
recommended,  minimum  basic  set  of  DIS  PDUs  for  a  simulator, 

6.1  Comparing  RAN  and  RAAF  Simulator  DIS  Interfaces 

The  PDUs  supported  by  DIS  Interfaces  of  ADF  simulators  are  compared  in  Table  10, 
and  the  recommended,  minimum,  basic  set  of  DIS  PDUs  (discussed  in  section  6.3)  are 
shown  in  shaded  cells  in  Table  10. 

PDU  types  that  are  only  supported  by  simulators  for  internal  simulator  component 
communications  are  marked  as  not  supported  (eg.  X).  PDU  types  that  should  be  added 
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Table  10.  DIS  PDUs  Supported  in  RAN  and  RAAF  simulators 


PDU 

TyPe 

PDU  Name 

IOTTF 

CSTT 

FFG 

UP 

AP-3C 

OMS 

ADGESIM 

1 

Entity  State 

✓ 

✓ 

✓ 

✓ 

✓ 

2 

Fire 

✓ 

✓ 

✓ 

✓ 

✓ 

3 

Detonation 

✓ 

✓ 

✓ 

✓ 

✓ 

4 

Collision 

✓ 

✓ 

✓ 

✓ 

X 

11 

Create  Entity 

✓ 

X 

X 

X 

X 

12 

Remove  Entity 

✓ 

X 

X 

X 

X 

13 

Start/Resume 

✓ 

✓ 

✓ 

✓ 

X 

14 

Stop/Freeze 

✓ 

✓ 

✓ 

✓ 

X 

15 

Acknowledge 

✓ 

✓ 

✓ 

✓ 

X 

19 

Set  Data 

X 

X 

X 

X 

✓ 

20 

Data 

X 

✓ 

✓ 

X 

X 

22 

Comment 

✓ 

X 

X 

X 

X 

23 

Electromagnetic 

Emission 

✓ 

✓ 

✓ 

✓ 

✓ 

25 

Transmitter 

✓ 

✓ 

✓ 

X 

✓ 

26 

Signal 

✓ 

✓ 

✓ 

X 

✓ 

27 

Receiver 

✓ 

✓ 

✓ 

X 

✓ 

28 

IFF/ATC/NAVAIDS 

✓ 

✓ 

✓ 

X 

✓ 

29 

Underwater  Acoustic 

X 

✓ 

✓ 

- 

X 

31 

Intercom  Signal 

X 

✓ 

X 

X 

X 

41 

Environmental  Process 

✓ 

X 

X 

X 

X 

51 

Create  Entity  -  R 

✓ 

X 

X 

X 

X 

52 

Remove  Entity  -  R 

✓ 

X 

X 

X 

X 

53 

Start/Resume  -  R 

✓ 

X 

X 

X 

X 

54 

Stop  Freeze  -  R 

✓ 

X 

X 

X 

X 

55 

Acknowledge  -  R 

✓ 

✓ 

X 

X 

X 

57 

Action  Response  -  R 

X 

✓ 

X 

X 

X 

62 

Comment  -  R 

✓ 

X 

X 

X 

X 

65 

Record  - R 

X 

✓ 

X 

X 

X 

66 

Collision  Elastic 

✓ 

X 

X 

X 

X 

67 

Entity  State  Update 

✓ 

X 

X 

X 

X 

220 

FFG  Underwater  Environment 

X 

X 

✓ 

X 

X 

221 

RAN  FFG  UP  Chaff 

X 

X 

✓ 

X 

X 

231 

BFTT  Chaff 

* 

X 

✓ 

X 

X 

232 

BFTT  Environment 

X 

X 

✓ 

X 

X 

233 

BFTT  Jammer 

X 

X 

✓ 

X 

X 

235 

BFTT  Supplemental 
Electromagnetic  Emission 

X 

X 

✓ 

X 

X 

tbd 

RAN  FFG  UP 

Electromagnetic  Emission 

X 

X 

✓ 

X 

X 

tbd 

RAN  FFG  UP  Link -11/16 

X 

X 

tbd 

X 

X 

? 

Acoustic  (?) 

X 

X 

X 

✓ 

X 
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(ie  the  PDU  has  not  been  implemented  in  the  simulator)  or  modified  (not  compatible) 
in  any  particular  simulator  compared  in  Table  10  are  shown  in  red  eg  X* 

The  following  can  be  concluded  from  table  10: 

a)  The  Entity  State  PDU  is  the  most  fundamental  DIS  PDU  and  is  used  by  all 
simulators. 

b)  Similarly  the  Fire  and  Detonation  PDUs  are  supported  by  all  simulators 
although  the  FFG  UP  simulator  ignores  received  Fire  PDUs  (see  Table  6)  as  this 
PDU  most  likely  has  no  effect  on  any  FFG  UP  sub-systems.  It  should  be 
important  for  all  systems  to  transmit  the  Fire  PDU  to  allow  for  visual  and  aural 
effects  where  required,  however  it  may  be  most  important  for  systems  to 
transmit  Fire  PDUs  for  use  in  DIS  After  Action  Review  Debriefing  tools. 

c)  The  Collision  PDU  is  supported  by  all  simulators  except  the  ADGESIM 
simulator.  The  ADGESIM  simulator  does  not  have  an  ownship  entity  therefore 
ADGESIM  itself  cannot  collide  with  anything  and  has  no  requirement  for  a 
Collision  PDU  [8-9],  Currently  ADGESIM  only  generates  air  entities  and 
collision  information  is  probably  more  important  for  land  and  sea  entities  as  a 
collision  with  an  air  entity  would  most  likely  result  in  the  destruction  of  that  air 
entity.  To  support  sea  and  land  entities  from  within  ADGESIM,  each  ADGESIM 
application  will  have  Collision  PDU  support  added  if  required  and  when  time 
permits. 

d)  All  simulators  support  the  Start/ Resume,  Stop/ Freeze  and  Acknowledge 
Simulation  Management  Family  PDUs  except  the  ADGESIM  simulator. 
Support  for  these  management  PDUs  will  be  added  to  ADGESIM.  Simulators 
do  not  need  to  be  able  to  control  an  exercise  (transmit  the  Start/ Resume  and 
Stop/ Freeze  PDUs  and  react  to  the  Acknowledge  PDU)  however  it  is  important 
to  be  able  to  be  managed  by  responding  to  Start/ Resume  and  Stop/Freeze 
PDUs  and  transmitting  Acknowledge  PDUs. 

e)  The  Set  Data  PDU  is  only  supported  by  the  ADGESIM  simulator  to 
communicate  with  other  (DIS)  applications  on  the  DIS  network.  Because  it  is  a 
DIS  PDU  it  will  be  recorded  by  a  DIS  Data  Logger  application  and  remote 
applications  will  be  correctly  restarted  when  data  (including  the  Set  Data  PDU) 
is  replayed  by  the  DIS  Data  Logger.  Because  the  Set  Data  PDU  is  a  simple  PDU, 
it  is  easy  to  add  this  capability  to  a  simulator. 

f)  Similarly  the  Comment  PDU  is  a  simple,  easy  to  implement,  useful  PDU  as  it 
allows  instructor  and/or  student  comments  to  be  recorded  and  played  back 
(correctly  synchronised  along  with  all  the  other  DIS  data)  by  a  DIS  Data  Logger. 
The  Comment  PDU  capability  would  be  very  useful  in  a  DIS  After  Action 
Review  Debriefing  process. 

g)  The  Electromagnetic  Emission  PDU  is  supported  by  all  simulators  and  is 
required  to  enable  Electronic  Warfare  training. 

h)  The  IFF/ATC/NAVAIDS  PDU  is  supported  by  all  simulators  except  the  AP-3C 

simulator. 
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i)  The  Radio  Communications  Family  (Transmitter,  Signal  and  Receiver)  PDUs 
are  supported  by  all  simulators  except  the  AP-3C  simulator.  These  PDUs  are 
fundamental  in  that  they  allow  simulators  to  interoperate  using  their  simulator 
radio  and  intercom  systems  via  an  IEEE  standardised  mechanism. 

j)  The  Underwater  Acoustic  PDU  is  not  considered  as  part  of  the  Common  DIS 
PDU  Set.  It  is  supported  by  all  the  simulators  except  ADGESIM  (the  AP-3C  has 
its  own  proprietary  version  of  the  Underwater  Acoustic  PDU)  because  all  the 
other  simulators  considered  carry  out  Anti-Submarine  Warfare  activities  which 
is  not  the  case  for  all  major  ADF  platforms. 

k)  If  tire  AP-3C  simulator  is  to  be  used  in  ADF  distributed  simulation,  training 
exercises  its  DIS  Interface  will  need  to  be  modified  to  be  more  interoperable 
with  the  other  ADF  simulators  under  consideration  in  this  report. 

6.2  Analysis  of  DIS  PDU  Traffic  From  Several  Major  Exercises 

The  analysis  of  DIS  PDUs  recorded  during  four  coalition  demonstration  exercises 
carried  out  at  HMAS  Watson  between  the  RAN  and  USN  is  shown  in  Table  11. 
However  it  should  be  noted  that  some  PDU  traffic  may  have  been  filtered  out  at  the  US 
end  of  the  WAN  connection  between  the  USA  and  HMAS  Watson.  As  for  Table  10  the 
recommended,  minimum  basic  set  of  DIS  PDUs  (discussed  in  section  6.3)  is  shown  in 
shaded  cells  in  Table  11. 

The  following  can  be  concluded  from  Table  11: 

a)  The  vast  majority  of  the  PDUs  (99.25%  for  the  Sept  03/1  exercise,  99.46%  for 
Sept  03/2,  99.9%  for  Feb  03  and  97.2%  for  Nov  01  exercise)  are  contained  within 
the  recommended  PDU  set, 

b)  The  major  portion  (approximately  two  thirds)  of  all  the  PDUs  (64.74%  for  the 
Sept  03/1  exercise,  62.66%  for  Sept  03/2,  68.31%  for  Feb  03  and  69.60%  for  Nov 
01  exercise)  belong  to  the  Radio  Communications  family  (Transmit,  Signal  and 
Receive)  PDUs, 

c)  Most  of  the  remaining  PDU  traffic  (27.88%  for  the  Sept  03/1  exercise,  30.66%  for 
Sept  03/2,  22.19%  for  Feb  03  and  19.57%  for  Nov  01  exercise)  is  that  generated 
by  the  Entity  State  PDU, 

d)  The  Fire  and  Detonate  PDUs  each  account  for  a  maximum  of  0.01%  of  the  total 
number  of  PDUs, 

e)  The  Simulation  Management  family  PDUs  (individual  PDU  breakdown  shown 
below  in  Table  12)  on  average  account  for  approximately  0.2%  of  the  total 
number  of  PDUs, 

f)  The  Electromagnetic  Emission  PDU  accounts  for  approximately  between  2% 
and  8%  of  the  total  number  of  PDUs, 

g)  Similarly  the  IFF  PDU  approximately  accounts  for  between  1%  and  5%  of  the 
total  number  of  PDUs, 

h)  The  Underwater  Acoustic  (UA)  PDU  (which  is  not  in  the  recommended  PDU 
set  because  not  all  platforms  will  have/require  an  Underwater  Warfare 
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capability)  only  accounts  for  a  very  minor  part  (a  maximum  of  0.05%)  of  the 
total  number  of  PDUs, 

i)  The  experimental  BFTT  Supplemental  Electromagnetic  Emission  (BSEE)  PDU 
can  account  for  up  to  3%  of  the  total  number  of  PDUs,  and 

j)  The  experimental  BFTT  Multiphase  Electromagnetic  Emission  (BMEE)  PDU  can 
account  for  up  to  0.5%  of  the  total  number  of  PDUs. 

Table  11.  Number  of  DIS  PDUs  for  four  RAN/USN  Coalition  Exercises  (ES  indicates  Entity 
State  PDU,  EE  indicates  Electromagnetic  Emission  PDU ,  TX  indicates 
Transmission  PDU,  RX  indicates  Receiver  PDU,  UA  indicates  Underwater 
Acoustics  PDU,  SM  indicates  Simulation  Management  PDUs,  BSEE  indicates 
Experimental  BFTT  Supplemental  Electromagnetic  Emission  PDU  and  BMEE 
indicates  the  Experimental  BFTT  Multiphase  Electromagnetic  Emission  PDU. 


PDU  Type 

ES 

FIRE 

DET 

SM 

EE 

TX 

SIG 

RX 

IFF 

UA 

BSEE 

BMEE 

TOTAL 

Sept  03/1 

441,372 

!■! 

1| 

7,072 

106,058 

826,103 

92,844 

56,064 

862 

3,729 

7,246 

1,583,044 

% 

MM 

0.45% 

2,63% 

52.18% 

5.86% 

3.54% 

0.24% 

0.46% 

Sept  03/2 

625,509 

10 

10 

4,343 

47,577 

202,598 

964,020 

111,490 

72,591 

778 

3,723 

7,371 

tmmmm 

% 

0.00% 

0.21% 

2.33% 

9.93% 

47.26% 

WTM 

Ml 

0.18% 

0,36% 

Feb  03 

267718 

118 

106 

0 

155452 

484742 

183823 

16364 

87 

1,206,455 

% 

22.19% 

0.01% 

0.01% 

0.00% 

8.13% 

12.89% 

40.18% 

15.24% 

1.36% 

Nov  01 

83122 

10 

9 

514 

Bi 

65970 

20321 

11883 

% 

19.57% 

0.00% 

0.00% 

0.12% 

3.13% 

10.32% 

43.75% 

15.53% 

4.78% 

2.80% 

The  breakdown  of  the  Simulation  Management  Family  PDUs  is  shown  in  Table  12. 

The  following  can  be  concluded  from  Table  12: 

a)  In  the  Sept  03/1  and  Nov  01  exercises,  all  the  Simulation  Management  Family 
PDUs  were  Comment  PDUs.  Approximately  94%  (4071  out  of  4343)  of  the 
Simulation  Management  Family  PDUs  from  the  I/ITSEC  2001  exercise  were 
Comment  PDUs. 

b)  In  the  second  September  2003  CReaMS  exercise  (Sept  03  /  2)  of  the  32 
participating  simulation  applications  (32  different  unique  Site:Application 
doublets)  only  two  of  these  simulation  applications  issued  Start  PDUs  whereas 
seven  simulation  applications  issued  Acknowledge  PDUs  in  response  to  all  of 
the  Start  /  Stop  PDUs  issued. 

c)  Similarly  four  different  simulation  applications  issued  a  total  of  14  Action 
Request  PDUs.  In  response  to  the  issuing  of  these  Action  Request  PDUs  six 
simulation  applications  (including  the  four  simulation  applications  that  issued 
the  Action  Request  PDUs)  issued  a  total  of  60  Action  Response  PDUs. 
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d)  Of  the  32  simulation  applications  participating  in  die  second  September  2003 
CReaMS  exercise,  seven  had  Simulation  Management  capabilities. 


Table  12.  Exercise  Simulation  Management  Family  PDU  Breakdown 


Simulation 

Management 

PDUs 

Stop 

Acknowledge 

Action 

Request 

Action 

Response 

Comment 

Total 

Sept  03/1 

0 

0 

gjsgna 

7072 

wmm 

Sept  03/2 

26 

2 

14 

4343 

Nov  01 

0 

0 

6.3  The  Recommended,  Basic,  DIS  PDU  Set 

The  recommended,  minimum,  basic  set  of  DIS  PDUs  that  would  enable  a  simulator  to 
provide  a  sufficient  level  of  application  protocol  interoperability  is  shown  in  Table  13. 

Table  14  shows  how  the  recommended,  minimum,  basic  set  of  PDUs  is  supported  in 
ADF  simulators. 

The  following  can  be  concluded  from  Table  14: 

a)  Only  the  RAN  HMAS  Watson  IOTTF  simulator  is  fully  compliant  with  the 
recommended,  minimum  PDU  set. 

b)  The  RAN  HMAS  Watson  CSTT  Anzac  ship  simulator  and  the  RAN  FFG  UP 
model  only  require  support  for  the  Comment  PDU  to  be  fully  compliant  with 
tiie  recommended,  minimum,  basic  PDU  set.  A  simple,  stand-alone,  Windows 
simulation  application,  which  could  be  easily  and  quickly  written,  could 
provide  the  required  Comment  PDU  support  for  any  DIS  simulator. 

The  migration  path  to  make  the  DSTO  developed  ADGESIM  simulator  fully  compliant 
with  the  recommended,  minimum,  basic  set  of  PDUs  will  be  the  subject  of  a  separate 
report. 
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Table  13.  The  Recommended,  Minimum,  Basic  Set  ofDIS  PDUs 


Entity 

Information 

Interaction 


Management 


PDU  I  PDU  Name 


Comments 


1 

Entity  State 

2 

Fire 

3 

Detonation 

4 

Collision 

orientation  and  appearance  are 
conveyed  by  this  PDU. 


Communicates  information  about  a 
collision  between  two  entities  or 
between  an  entity  and  a  terrain  object. 


Required  to  control  the  whole 
simulation  exercise  from  anywhere  on 
the  DIS  network. 


Comment 


Distributed 

Emission 

Regeneration 


Radio 

Communications 


synchronously  replayed  using  a  DIS 
Data  Logger  application. 


Required  for  Electronic  Warfare 
training. 


Electromagnetic 

Emission 


28  IFF  All  military  platforms  of  significance 

ATC  support  IFF. 

NAVAIDS 


interoperability  between  simulators,  A 
fundamental  capability  of  any  DIS 
simulator. 


lEsm 


25 


26 


27  Receiver 
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Table  14.  Recommended,  Minimum,  Basic  Set  PDU  Support  in  ADF  simulators  (where  Eli  = 
Entity  Information  and  Interaction  Family  PDUs,  SM  =  Simulation  Management 
Family  PDUs,  EM  =  Distributed  Emission  Regeneration  Family  PDUs  and  RC  = 
Radio  Communications  Family  PDUs) 


System 

DIS  Interface  Details 

Eli 

SM 

EM 

RC 

RAN  IOTTF  (FFG) 

IEEE  1278.1a 

✓ 

✓ 

✓ 

✓ 

RAN  CSTT  (Anzac) 

IEEE  1278.1a 

✓ 

✓i) 

✓ 

✓ 

RAN  FFG  UP 

IEEE  1278.1a 
(Including  Experimental) 

✓ 

f/i) 

✓ 

✓ 

RAN  Seasprite 

IEEE  1278.1a 
(Including  Experimental) 

? 

7 

? 

? 

RAAF  AP-3C  OMS 

DIS  Version  3  or  4  ? 
IST-CD-93-40  (7  March  1994) 

✓ 

✓l) 

X 

RAAF  ADGESIM 

IEEE  1278.1a 

t/Vi 

X 

✓ 

✓ 

1)  No  Comment  PDU 

2)  No  IFF  PDU 

3)  No  Collision  PDU 

7.  DIS  or  HLA? 


Distributed  Interactive  Simulation  has  already  been  described  in  detail  in  sections  3 
and  4. 

7.1  What  Is  HLA? 

High  Level  Architecture  (HLA)  [33]  is  a  methodology  designed  to  support  distributed 
simulation  exercises.  It  is  defined  by  the  rules  that  specify  how  simulations  interact. 
The  HLA  Run  Time  Infrastructure  (RTI)  is  a  programming  toolkit  that  provides  the 
means  to  exchange  data  during  execution.  HLA  designates  simulations  as  federates 
and  a  set  of  participating  federates  as  a  federation.  Each  federate  has  an  associated 
Simulation  Object  Model  (SOM)  that  describes  its  data  modeling  requirements,  and 
similarly  a  federation  has  a  Federation  Object  Model  (FOM)  identifying  the  attributes 
and  interactions  supported  by  the  federation  [11], 

Federates  send  information  via  or  using  the  HLA  RTI,  which  in  turn  distributes  the 
information  to  the  other  federates  over  the  simulation  network.  For  federates  to  be 
interoperable  within  a  federation,  they  must  all  be  able  to  subscribe  and  publish  to  the 
same  FOM  and  use  the  same  version  of  the  same  manufacturer's  RTI  [11].  Because  RTIs 
are  expensive  this  is  a  major  problem  in  using  HLA  in  a  large  exercise  eg  CReaMS. 

The  Real-time  Platform  Reference  (RPR)  FOM  is  a  HLA  description  of  the  DIS  PDU 
[34-36]  structures  and  the  data  contained  within  those  structures  and  has  been 
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proposed  to  assist  with  conversion  of  DIS-compatible  systems  to  HLA  to  promote 
interoperability.  Federation  designers  can  use  the  RPR-FOM  as  a  starting  point  FOM  to 
further  develop  their  own  FOMs  for  their  own  applications  to  allow  interoperability 
between  DIS  and  HLA  applications  via  a  D IS/ HLA  Gateway  application. 

7.2  Advanced  Distributed  Simulation  (ADS)  For  The  ADF 

It  may  take  as  long  as  10  years  for  a  military  simulator  to  pass  through  its  design  and 
development  stages  to  be  accepted  into  the  ADF.  HLA  has  been  in  development  since 
1996  and  has  had  components  pass  through  the  IEEE  standardisation  process  since 
September  2000  [33,  37-40].  As  far  as  the  author  of  this  report  is  aware,  HLA  is  not 
currently  proposed  or  used  operationally  in  any  RAN  or  RAAF  training  simulators. 

The  ADF  simulators  described  in  Table  6  are  all  DIS  simulators.  The  US  Navy  is 
currently  fitting  all  its  major  platforms  with  DIS  BFTT  systems.  The  Australian  Navy 
FFG  Upgrade  project  will  begin  to  bring  Australian  FFG  ships  into  service  with  similar 
DIS  systems  by  2005  [10].  In  the  USAF  Distributed  Mission  Training  (DMT)  program  F- 
15  and  F-16  Mission  Training  Centers  support  DIS  and  HLA  [41-45].  The  Joint  Strike 
Fighter  (JSF)  simulation  architecture  will  use  HLA  [46]. 

The  ADF  simulation  training  community  is  small  and  is  mainly  interested  in  real-time 
Human-In-The-Loop  (HIL)  training.  ADF  simulator  applications  need  to  be 
interoperable  with  each  other  and  with  simulation  applications  from  Australia's 
coalition  partners.  Whereas  the  US  DMT  cockpits  can  interoperate  using  HLA 
(probably  a  RPR-FOM  variant)  no  HLA  simulators  have  participated  in  any  of  the 
three  RAN  -  USN  CReaMS  training  exercises  carried  out  so  far  [47], 

The  US  Simulation  community  is  much  larger  and  has  many  groups  interested  in  many 
areas  of  simulation  other  than  real-time  training.  In  the  USA  interoperability  is  a  major 
concern  to  almost  every  DoD  simulation  program,  new  and  legacy.  While  the  DIS 
community  has  evolved  certain  basic  philosophies  and  tenets  governing  distributed 
simulation,  HLA's  architecture  allows  (has  been  designed  to  allow)  the  distributed 
community  to  be  split  into  separate  federations,  each  of  which  is  free  to  define  their 
own  data  formats  and  philosophies.  While  a  given  HLA  federation  has  greater 
flexibility  to  define  and  control  its  own  interfaces,  the  resultant  diversity  only 
complicates  future  efforts  to  interface  between  such  federations,  much  less  to  ensure 
that  they  are  truly  interoperable  [48]. 

Compared  to  DIS,  HLA  is  still  a  developing  technology.  Having  the  DIS  PDU 
structures,  data  handling  algorithms  (eg  dead-reckoning)  and  data  stored  in  those 
structures  standardized  by  the  IEEE  has  ensured  a  certain  degree  of  out-the-box 
interoperability.  Not  knowing  what  data  is  available  and  how  it  is  structured  and 
distributed  in  HLA  network  packets  has  been  previously  described  as  a  security 
feature  by  some  in  the  HLA  community.  It  is  however  interesting  to  note  that  the 
Simulation  Interoperability  Standards  Organisation  (SISO)  is  now  proposing  to 
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investigate  the  production  of  an  Open  Run-Time  Infrastructure  Protocol  Standard 
which  will  standardize  HLA  RTI  message  formats  and  data  handling  algorithms  [49]  - 
similar  to  the  IEEE  standards  that  have  existed  since  the  start  of  DIS. 

DIS  standards  development  ceased  shortly  after  HLA  was  mandated  by  the  US 
Department  of  Defence  and  the  USA  Defense  Modeling  and  Simulation  Office's 
(DMSO)  No  Play  -  No  Pay"  policy  came  into  existence.  It  is  a  little  known  fact  that 
training  simulators  were  always  exempted  from  this  mandate  [50], 

Current  (from  2000/2001)  US  DoD  policy  states  [51]: 

a)  HLA  shall  be  the  standard  technical  architecture  for  interoperability  among 
DoD  simulations, 

b)  All  planned  upgrades  or  significant  changes  (to  be  defined  by  each  DoD 
component)  shall  be  HLA  compliant, 

c)  Existing  non-HLA  compliant  simulations  intended  to  be  interoperable  shall  be 
HLA  compliant  based  on  DoD  Component  requirements,  resources  and 
priorities,  and 

d)  DoD  Components  shall  establish  their  own  policies  and  processes  for 
transitioning  their  simulations  to  HLA  or  excluding  them  based  on 
requirements,  resources.  Component  priorities,  or  security. 

It  is  up  to  each  US  DoD  Component  to  establish  its  own  HLA  migration  policy 
(including  exclusion)  based  on  requirements,  resources.  Component  priorities,  or 
security. 

In  September  2002,  DMSO  ceased  to  distribute  and  support  (free)  DMSO  developed 
HLA  RTIs  and  developers  were  instructed  to  purchase  commercial  versions  of  the  RTI. 
Although  HLA  was  originally  mandated  in  1996  [52-53],  problems  still  exist.  Federates 
typically  cannot  interoperate  unless  they  are  all  using  the  same  RTI  implementation 
[54],  Performance  problems  in  the  DMSO  RTIs  [55]  and  stability  problems  in  newer 
commercially  available  RTIs  [56]  have  also  been  reported. 

In  2003  SISO  formed  a  Study  Group  [ 57]  to  investigate  the  use  of  DIS  and  HLA. 
Amongst  the  tasks  of  this  group  are: 

a)  Perform  analysis  and  prepare  a  draft  set  of  proposed  changes  to  the  DIS  and 
HLA  RPR-FOM  Standards  as  well  as  the  Enumerations  that  address  the  issues. 

b)  Prepare  a  draft  set  of  DIS  design  guidelines  based  on  the  proposed  changes  to 
the  standards. 

c)  Review  the  findings  of  the  DIS  Study  Group  for  possible  extension  of  the  TEEE 
1278.1  and  IEEE  1278. 1A  standards. 
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7.3  Migration  to  HLA 

Eventually  HLA  interoperability  will  (may?)  be  required  for  ADF  simulators.  For  ADS 
simulators,  HLA  compliance  can  be  achieved  using  three  approaches  [58-62]  shown  in 
table  15. 


Table  15.  Ways  To  Achieve  HLA  Compliance 


Approach 

Cost 

Conversion  Time 

Speed  of  Operation 

Gateway/Translator 

Low 

Short 

Slowest 

Middleware/ Wrapper 

Medium 

Medium 

Fast 

Native 

High 

Long _ 

Fastest 

7.3.1  The  DIS/HLA  Gateway  Approach 

The  DIS/HLA  Gateway  is  a  stand-alone  simulation  application  (often  executing  on  a 
dedicated  computer)  that  translates  network  traffic  between  DIS  and  HLA  (conceptual) 
networks  [3, 59]. 

This  approach  is  especially  useful  for  legacy  systems  where  a  native  HLA  development 
process  would  be  high  risk,  expensive  and  difficult  to  justify.  The  Gateway  approach  is 
attractive  in  that  it  is  low  cost,  low  risk,  simple  and  quick  to  install  and  requires  no 
modification  of  the  legacy  simulator's  code  [62], 

A  Gateway  does  not  provide  support  for  the  full  range  of  HLA  capabilities  but  a  legacy 
system  is  not  normally  endowed  with  these  capabilities  anyway.  The  Gateway 
approach  may  also  add  considerable  latency.  DIS/HLA  Gateways  will  generally  only 
support  variants  of  the  Real-time  Platform  Reference  FOM  (RPR-FOM)  and,  unless 
source  code  is  available,  a  DIS/HLA  Gateway  may  be  rigidly  tied  to  a  particular  FOM 
or  a  particular  version  of  a  particular  FOM.  If  a  Gateway  is  no  longer  produced  or 
supported,  using  an  alternate  Gateway  that  supports  the  FOM  required  may  provide 
an  option  [62]. 

DIS/HLA  Gateways  mentioned  in  the  literature  are  the  University  Of  Central  Florida's 
Institute  of  Training  Gateway  [62]  (possibly  no  longer  available),  the  Naval  Air 
Warfare  Center  Training  Systems  Division's  (NAWTSD)  Simulation  Middleware 
Object  Classes  (SMOC)  Gateway  [58,  63]  and  the  MaK  Technologies  DIS/HLA 
Gateway  [64]. 

7.3.2  The  Middleware  HLA  Migration  Approach 

The  Gateway  approach  is  a  convenient,  low  cost,  low  risk  option  to  add  HLA 
capabilities  to  a  legacy  DIS  simulator  because  no  modification  of  the  legacy  simulator's 
code  is  required. 
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The  middleware/ wrapper  approach  utilises  a  software  toolkit  that  encapsulates 
common  DIS/HLA  tasks  into  a  library  of  pre-tested  routines.  This  decreases  the  cost 
and  risk  of  adding  DIS  or  HLA  to  a  simulation  application  [65].  The  same  library  of 
pre-tested  routines  can  actually  support  both  DIS  and  HLA  therefore  allowing  a 
simulation  application  to  either  support  both  DIS  and  HLA  concurrently  or  to  support 
either  DIS  or  HLA  and  to  then  be  easily  modified  at  a  later  time  to  support  the  other 
option.  Therefore  a  simulation  application  can  be  developed  to  support  DIS  and  can  be 
easily  modified  to  support  HLA  at  a  later  time.  However  simulation  applications 
developed  using  tire  middleware  approach  are  then  tightly  bound  to  the  vendor's 
middleware  software. 

Similarly  to  tire  Gateway  approach  the  middleware  approach  may  not  allow  the 
simulator  to  take  advantage  of  all  HLA  specific  features. 

Because  the  middleware  approach  requires  software  development,  it  is  more  costly, 
takes  more  time  and  is  higher  risk  but  will  add  less  latency  than  the  Gateway 
approach.  Because  the  middleware  toolkit  manufacturer  has  developed  and  tested  its 
software  toolkit,  it  will  be  less  costly,  lower  risk,  take  less  development  time  but 
probably  have  a  (slightly)  greater  latency  than  if  a  native  HLA  approach  was  used. 

Tire  Naval  Air  Warfare  Center  Training  Systems  Division's  (NAWTSD)  Simulation 
Middleware  Object  Classes  (SMOC)  toolkit  [63]  and  the  MaK  Technologies  VR-Link 
toolkit  [64]  are  DIS/HLA  middleware  toolkits. 

7 .3.3  The  Native  HLA  Migration  Approach 

The  native  HLA  approach  is  the  highest  risk,  longest  development  time  and  the  most 
costly  of  the  three  HLA  migration  approaches.  However  once  developed  and 
debugged,  the  native  HLA  approach  should  add  the  least  latency  and  should  be  able  to 
support  any  HLA  feature  required.  Supporting  different  FOMs  may  require  constant 
and  considerable  software  development  at  considerable  cost.  Standardizing  the  HLA 
RTI  API  [38]  (no  DIS  API  standard  exists)  will  have  reduced  this  cost  and  further 
standardizing  the  HLA  RTI  message  formats  and  data  handling  algorithms  [49] 
(similar  to  the  IEEE  standards  that  have  existed  since  the  start  of  DIS)  will  further 
reduce  this  cost. 

7.4  DIS  or  HLA  -  A  Way  Forward 

As  shown  in  Table  3,  current  RAAF  and  RAN  training  simulators  all  use  DIS.  At 
SimTecT  2002  HLA  compliant  Army  Synthetic  Environment  (ASE)  simulators 
developed  by  the  Army  Simulation  Office  were  connected  to  several  DIS  compliant 
systems  using  the  MaK  Technologies  DIS/HLA  Gateway  thus  demonstrating 
interoperability  between  HLA  and  DIS  simulators  [66]. 
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A  standard  ADF  Reference  FOM  has  not  yet  been  developed.  A  US  DoD  Reference 
FOM  has  also  not  yet  been  developed.  The  Real-time  Platform  Reference  (RPR)  FOM  is 
a  HLA  description  of  the  DIS  PDU  [34-36]  structures  has  been  developed  to  enable 
interoperability  between  DIS  and  HLA  systems.  The  US  Naval  Training  Meta-FOM 
(NTFM)  Project  [67-69]  aims  to  provide  meaningful  US  Navy,  Marine  Corps,  Joint  and 
Coalition  training  by  achieving  interoperability  between  US  Navy  training  simulation 
systems  using  HLA  and  is  based  on  the  RPR-FOM. 

Supporting  different,  developing  FOMs  may  require  constant  and  considerable 
software  development  at  considerable  cost  Standardising  the  HLA  RTI  API  (IEEE 
1516.1)  [38]  (no  DIS  API  standard  exists)  has  reduced,  or  is  reducing,  this  cost  and 
further  standardising  the  HLA  RTI  message  formats  and  data  handling  algorithms  [49] 
(similar  to  the  IEEE  standards  that  have  existed  since  die  start  of  DIS)  will  further 
reduce  this  cost  again. 

In  September  2002,  the  USA  Defense  Modeling  and  Simulation  Office  (DMSO)  ceased 
to  distribute  and  support  (free)  DMSO  developed  HLA  RTIs.  RTIs  must  now  be 
commercially  purchased. 

Federates  typically  cannot  interoperate  unless  they  are  all  using  the  same  RTI 
implementation  [54],  RTI  performance  and  stability  problems  [55-56]  have  been 
reported, 

DIS  standards  development  ceased  shordy  after  HLA  was  mandated  by  the  US  DoD, 
DMSO's  "No  Play  -  No  Pay"  policy  came  into  existence  and  with  die  release  of  the  last 
DIS  IEEE  1278.1 A  standard  in  1998  until  2003  when  SISO  formed  a  Study  Group  [57]  to 
prepare  a  draft  set  of  proposed  changes  to  the  DIS  and  HLA  RPR-FOM  Standards  for 
possible  extension  of  the  IEEE  1278.1  and  IEEE  1278.1  A  standards. 

In  summary  DIS  is  recommended  for  use  in  RAN  and  RAAF  simulation  applications 
because: 

a)  RAN  and  RAAF  use  of  simulation  is  (currendy)  for  real-time  training, 

b)  DIS  is  a  mature  (well  used  and  standardized)  technology, 

c)  HLA  is  a  developing  and  slowly  maturing  technology, 

d)  DIS  is  currentiy  used  by  all  major  RAN  and  RAAF  training  simulators, 

e)  DIS  has  been  used  in  all  three  RAN  /  USN  CReaMS  training  exercises, 

f)  HLA  has  not  been  available  for  use  in  any  CReaMS  training  exercises, 

g)  USAF  DMT  simulators  support  both  DIS  and  HLA, 

h)  DIS  can  be  used  to  interoperate  with  real  USN  BFTT  ship  systems,  and 

i)  DIS  will  be  able  to  interoperate  with  real  RAN  FFG  Upgrade  ship  systems. 
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8.  Conclusions 


The  processes  used  to  provide  a  recommended,  minimum,  basic  set  of  DIS  PDUs  for 
the  AEW&C  OMS  simulator  have  been  documented  in  this  report. 

The  recommended,  minimum  basic  set  of  DIS  PDUs  for  ADF  training  simulators  is 
shown  in  Table  13. 

This  basic  set  of  DIS  PDUs  should  provide  sufficient,  application  protocol 
interoperability  to  enable  the  AEW&C  OMS  simulator  to  participate  in  a  DIS,  Wide 
Area  Network,  training  exercise  at  the  time  the  simulator  is  accepted  by  the 
Commonwealth. 


All  major  ADF  platform  simulators  should,  as  a  starting  point,  provide  support  for  the 
complete,  recommended,  minimum  basic  set  of  DIS  PDUs. 

The  training  functions  carried  out  by  the  platform  to  be  simulated  should  be  analysed 
(a  training  needs  analysis)  and  any  additional  PDUs  required  to  support  these 
functions  should  be  added  to  the  recommended,  minimum,  basic  set  of  DIS  PDUs. 

Support  for  the  recommended,  minimum,  basic  set  of  DIS  PDUs  requires  support  for 
the  latest  1998  IEEE  1278.1 A  version  of  DIS. 

To  support  legacy  DIS  simulators  (eg  USN  BFTT)  ADF  DIS  simulators  should 
concurrently  support  both  DIS  versions  5  and  6. 

Current  ADF  simulators  already  support  most  of  the  recommended,  minimum  basic 
set  of  DIS  PDUs. 


DIS  is  recommended  for  RAN  and  RAAF  simulators.  HLA  is  discounted  for  reasons 
discussed  in  detail  in  section  7. 

The  DSTO  developed  ADGESIM  simulator  will  be  migrated  to  the  recommended, 
minimum,  basic  set  of  PDUs.  The  migration  path  required  will  be  the  subject  of  a 
separate  follow  on  report  [70], 

To  make  way  for  HLA,  DIS  standards  development  ceased  after  the  release  of  the  last 
DIS  IEEE  1278.1A  standard  in  1998.  DIS  standards  development  has  now  (2003) 
restarted  and  SISO  has  formed  a  Study  Group  [57]  to  prepare  a  draft  set  of  proposed 
changes  to  the  DIS  and  HLA  RPR-FOM  Standards  for  possible  extension  of  the  TFFF 
1278.1  and  IEEE  1278.1A  standards.  This  current  report  could  be  used  as  an  Australian 
contribution  to  a  DIS  Design  Guide  that  has  been  proposed  as  one  of  the  outputs  of  the 
new  SISO  DIS  Working  Group. 
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Appendix  A:  Tactical  Data  Link  (Simulation) 

Interoperability 


In  real  combat,  units  and  individuals  coordinate  with  each  other  using  voice  and  Data 
Links  with  Data  Links  seen  as  a  key  component  in  providing  the  necessary  situation 
awareness  to  win  a  modern  war  [71]. 

As  real  Data  Link  information  is  distributed  using  radio  communications  a  Data  Link 
simulation  capability  was  included  in  the  DIS  Radio  Communications  PDU  family  [25], 
However  as  suitable  Data  Link  enumeration  values  have  only  recently  become 
available  [27]  each  (US)  service  has  developed  its  own  "proprietary"  simulated  data  link 
capabilities  and  many  devices  and  protocols  are  required  to  interface  all  participants  in 
a  large  simulation.  This  is  compounded  further  by  the  development  of  new  battlefield 
tactical  data  links  in  recent  years,  and  the  requirement  for  all  link  devices  to 
interoperate  [71], 

Another  way  to  incorporate  Data  Link  capability  in  a  simulation  is  to  use  messages  that 
employ  identical  data,  data  structures  and  rules  as  the  real  military  Data  Link  messages 

The  US  Department  of  Defense  does  not  have  any  standard  or  minimum  set  of 
requirements  to  enable  interoperability  between  Data  Link  simulators  or  Data  Link 
simulators  and  real  platform  fielded  systems.  Real  Data  Link  messages  produced  by 
simulators  are  simulated  real  messages  and  cannot  be  transmitted  using  the  same 
medium  (eg  radio  transmissions)  and  thus  these  simulated  real  messages  (along  with 
real  messages)  must  be  placed  within  another  message  (eg  wrapper)  when  transmitted 
between  Data  Link  simulators  and  fielded  Data  Link  systems  [71]. 

Various  wrapper  message  formats  can  be  used  [71].  However  the  NATO  Standard 
STANAG  5602  Standard  Interface  for  Multiple  Link  Evaluation  (SIMPLE)  [72]  is  the 
message  wrapper  that  has  been  used  in  US,  NATO  and  ADF  distributed  simulation 
exercises  [11,  47,  73-74].  Using  real  Data  Link  messages  has  the  advantage  of  allowing  a 
simulator  to  not  only  interface  to  other  high-fidelity  simulators  but  to  real  fielded 
platform  systems  as  well.  Using  this  method  in  recent  RAN  /  USN  CReaMS  coalition 
training  exercises  [47,  73]  enabled  successful  Data  Link  interoperability  to  be  achieved 
between  a  RAN  training  simulator  and  a  real  USN  Navy  ship  (USN  Howard)  [47], 
Similar  Data  Link  interoperability  will  be  achievable  between  RAN  (and  USN)  training 
simulators  and  RAN  FFG  Upgrade  ships  when  the  FFG  ship  upgrades  have  been 
completed  [74], 
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